设计理念

设计理念

1. DDD架构演进

1.1 DDD依赖倒置架构

Vernon在它的《实现领域驱动设计》一书中提到了采用依赖倒置原则改进的方案。

所谓的依赖倒置原则指的是：高层模块不应该依赖于低层模块，两者都应该依赖于抽象，抽象不应该依赖于细节，细节应该依赖于抽象。

从图中可以看到，基础设施层位于其他所有层的上方，接口定义在其它层，基础实施实现这些接口。依赖原则的定义在DDD设计中可以改述为：领域层等其他层不应该依赖于基础设施层，两者都应该依赖于抽象，具体落地的时候，这些抽象的接口定义放在了领域层等下方层中。这也就是意味着一个重要的落地指导原则： 所有依赖基础实施实现的抽象接口，都应该定义在领域层或应用层中。
采用依赖倒置原则改进DDD分层架构除了上面说的DIP的好处外，还有什么好处吗？其实这种分层结构更加地高内聚低耦合。每一层只依赖于抽象，因为具体的实现在基础设施层，无需关心。只要抽象不变，就无需改动那一层，实现如果需要改变，只需要修改基础设施层就可以了。

1.2 SIDE-EFFECT-FREE模式和CQRS架构

SIDE-EFFECT-FREE模式被称为无副作用模式，熟悉函数时编程的朋友都知道，严格的函数就是一个无副作用的函数，对于一个给定的输入，总是返回固定的结果，通常查询功能就是一个函数，命令功能就不是一个函数，它通常会执行某些修改。
在DDD架构中，通常会将查询和命令操作分开，我们称之为CQRS(命令查询的责任分离Command Query Responsibility Segregation)，具体落地时，是否将Command和Query分开成两个项目可以看情况决定，大多数情况下放在一个项目可以提高业务内聚性，下面这张图是来自Martin Fowler的文章：CQRS。

这张图读写只是逻辑分离，物理层面还是使用了一个数据库，我们可以将数据库改成读库和写库做到物理分离，这时候就需要同步都写库，业界的解决方案是当写库发生更改时，通过Event事件机制通知读库进行同步。
最终CQRS落地的方案我们选择了简单化处理，物理层面还是使用一个数据库，查询的时候部分数据直接从数据库读取，部分数据使用到了Elasticsearch，当数据库发生更改时，会发送Event事件通知ES进行更新。当然我们还可以更加技术的处理这种同步，我们可以去除事件，直接监听Mysql的binlog更新ES，而我们也正是这样做的。

1.3 DDD和CQRS架构

根据上面的分析，最终落地的DDD+CQRS的架构使用了对称性架构，如下图所示：

架构中，我们平等的看待Web、RPC、DB、MQ等外部服务，基础实施依赖圆圈内部的抽象。
当一个命令Command请求过来时，会通过应用层的CommandService去协调领域层工作，而一个查询Query请求过来时，则直接通过基础实施的实现与数据库或者外部服务交互。再次强调，我们所有的抽象都定义在圆圈内部，实现都在基础设施。
在具体落地中我们发现，Query和Command的有一些数据和抽象服务是公用的，因此我们抽出了一个新的模块：Shared Data & Service，这个模块的功能为公用的数据对象和抽象接口。

2. DDD实践

我们结合上述的架构设计理念，在项目实践过程成中，根据项目模块依赖关系，下面这张图可能更为清晰:

• infrastructure层处于整个层次关系的最上层，负责与Web、DB、RPC、ES等外围系统进行交互。
• query层与application处于平级关系，query层做只读查询操作，将各种DO对象组装成DTO与前端或其他服务端进行交互。IQuery全部为抽象接口，具体实现交由infrastructure层，调用IQuery接口时，通过Spring依赖倒置注入infrastructure层实现类实例。
• application层依赖domain层负责业务逻辑的读写操作，本层的职责主要负责参数校验、一些简单的CURD、领域事件发送。
• domain层包含各个领域，每个领域对象包含各个实体、值对象、仓储层接口等。领域对象根据其属性可抽象出一些简单的行为，对于复杂的业务操作应该交由DomainService。仓储层接口全部为抽象接口，具体实现交由infrastructure层，调用仓储层接口时，通过Spring依赖倒置注入infrastructure层实现类实例。
• share层主要包含一些工具类、异常、常量、枚举、公共接口等，类似common包的地位.