模块化的DDD玩法

DDD诞生的主要目的是为了解决业务复杂度，DDD本身不要求你的系统架构必须采用服务化或者微服务。他更像一种方法论或心法，其与具体技术实现无关，但会对你领域划分起到理论支撑的作用。

在单体应用或者大模块应用中，哪怕服务本身业务场景比较小，但是如果本身业务迭代速度快，服务迭代复杂度高，DDD仍然可以是一个很好的选择。

通过DDD我们可以在一个大的或者小的，一些非服务化非微服务的，单体系统中进行模块化抽离，以进行一些模块化的架构和模式设计。

所以采用DDD可以帮助我们进行单体应用内的模块拆分，本质上DDD可以支撑模块化开发。

技术方案的建立

在研发流程和开发过程中哪些因素会影响最终的解决方案呢？

如功能要求、质量属性和技术约束等，另一方面也会受开发人员的经验、技术约束、时间和预算等因素的影响，所有这些因素都会影响解决方案。

技术选型或者解决方案采纳该应用针对的是为大多数开发人员所认可的。应用实现中需考虑额外的复杂性，因此DDD相比基于 CRUD 的常规应用更具意义。

领域划分心法

在领域划分上主领域进一步划分为多个子域。

为给出领域所需的功能，可以采用“事件风暴”（ Event Storming ）的方法在主领域的各子域中发现行为和事件。

比如我们一个系统划分为四个子域，即商品、支付、管理，以及用户访问。

从更高层次上看，架构中定义了一个 API 层、包含存储的四个模块，分别对应于所发现的四个子域，还包含一个用于通信的公共事件总线（EventBus）。

模块也相应地划分为四个子模块，并分别实现为独立的二进制文件，分别为：

- 处理所有请求的 Application

- 实现领域逻辑的 Domain

- 实现基础架构代码的 Infrastructure

- 及在 EventBus 上发布事件并且是模块间唯一共享组件的 IntegrationEvents。

CQRS变体

为分离应用内部的命令和查询，使用 CQRS 的一种变体。该 CQRS 变体针对命令所涉及的同一数据库表，在查询中使用了原始 SQL 和视图。使用 CQRS 或其他变体，应避免使应用过于复杂化。

EVENT BUS

模块间的集成是基于异步事件传输的。

事件传输使用了“发件箱模式”/“收件箱模式”（ outbox and inbox pattern ），以及基于内存中的 EventBus 代理。

为存储要发布的事件，发件箱模式在数据存储中添加了独立的表。事件的添加，实现中通过执行任务的命令，以及等同于命令的事务。

此后，这些事件通过单独的流程，转发到另一个模块的收件箱中。在该项目中，事件传输是通过各模块中的后台 Worker 实现的。该实现提供了多次交付和处理。

模块化

与微服务体系架构相比，模块化单体应用的主要差别之处在于部署方法和模块间通信。

在微服务架构中，每个模块都以独立的进程运行。模块间的通信必须使用网络实现，并且通常通过同步服务 API 调用（即 RPC，远程过程调用），或是使用代理（即消息传递）实现。微服务架构是一种分布式系统，具有分布式的所有优点和缺点。

对于模块化单体应用，则无需考虑分布式系统。所有模块均以同一进程运行，无需使用网络即可相互通信。各模块可以通过方法调用直接同步引用内存中对象，或是异步地使用运行于同一进程中的某个中介者（Mediator）。