领域驱动设计DDD实战进阶第一波(三)：开发通常业务的大健康行业直销系统（搭建支持DDD的轻量级框架二）

了解了DDD的好处与基本的核心组件后，咱们先不急着进入支持DDD思想的轻量级框架开发，也不急于直销系统需求分析和具体代码实现，咱们还少一块，那就是经典DDD的架构，只有了解了经典DDD的架构，你才能知道具体在哪层要实现哪些功能，编写哪些代码，具体在开发DDD的轻量级框架与具体模块代码实现时，才能作到有的放矢。

在这里须要说明的是，咱们的大健康行业直销系统有必定的业务复杂性，没有高并发、高性能的需求，因此不管是经销商上下文、产品上下文仍是订单上下文的具体实现，咱们都将遵循经典DDD架构，而不是CRUD简单方式或CQRS DDD架构的方式。

传统三层架构以及问题：

问题：
1.过度注重数据访问层，而不重视领域。
2.业务逻辑直接与数据访问层耦合，与领域为核心的DDD思想背道而驰。
3.没有一系列的模式与方法论指导这种分层架构的开发约束。

经典DDD架构：

1.基础结构层：整个产品或系统的底层支撑

a.经常使用工具、支撑功能：这个.netcore项目至少要实现如下的功能：Json配置文件的读取、WebApi返回给前端的基本格式对象的定义、Json序列化与反序列化、加密功能、依赖注入框架的二次封装等。

b.支持DDD框架：这个.net core 项目至少要实现如下的功能：聚合根接口定义、实体接口定义、值对象接口定义、仓储接口定义、仓储接口的EF Core顶层实现（工做单元模式）。

c.聚合根仓储实现：这个.netcore项目严格来说其实不属于基础结构层部分，只是因为习惯，把它放到基础结构层这个解决方案文件夹中。它实际上是引用了领域层的领域对象，而且 从领域层对应的聚合根仓储接口中继承，而后实现领域对象持久化到数据库，这样，仓储实现是依赖衣领对象，领域对象与领域逻辑就不须要依赖仓储。领域模型才是系统真正的核心。

2.领域层：界限上下文的领域逻辑

a.首先要实现这个界限上下文的领域对象的POCO模型。

b.而后针对这个界限上下文的全部领域对象，创建每一个领域对象本身的业务逻辑，注意的是，领域对象的业务逻辑最好不与仓储直接发生交互，就算领域逻辑要临时查询数据库也不要这样。

c.定义该界限上下文聚合根的仓储接口，这个接口表明的是聚合根与持久化打交道的基础约束，具体实现仍是在基础结构层的聚合根仓储中实现，这样就实现了解耦。把聚合根仓储接口定义在领域层的意义是能够为领域层的调用方-应用服务层的用例提供对聚合持久化支持。

d.定义该界限上下文的EF Core上下文接口并实现，这样就经过映射关系，EF Core就能够处理领域对象与数据库表之间的映射了。

3.应用服务层：界限上下文的用例

a.某个上下文的应用服务层的某个用例，经过调用领域对象的领域逻辑，完成相关领域逻辑的实现

b.领域逻辑完成后，应用服务层用例调用领域层的聚合根的仓储接口的方法，完成领域对象的预持久化。（应用服务经过基础结构层的依赖注入框架与Json配置文件找到聚合根仓储接口对应的实现）

c.应用服务层用例而后调用基础结构层的EFCore仓储接口的工做单元方式，完成真正的持久化。（应用服务经过基础接口层的依赖注入框架与Json配置文件找到顶层仓储接口对应的工做单元实现）

d.用例返回给接口层须要的前端所需的json对象格式。

4.接口层：很是薄的一层

a.只须要调用应用服务层用例

b.向前端返回所需的json对象格式

从上述架构特色能够看出，聚合根的仓储与领域逻辑彻底解耦，是经过应用服务层的用例将他们协调起来完成功能。

DDD实战进阶视频请关注微信公众号：MSSHCJ