领域驱动设计003分层架构

领域驱动中往往采用分层与6边形架构

整合ssm 与 DDD设计

用户接口层

1controller作为用户接口层负责与json序列化的框架等结合 ，处理接收映射参数

2 调用应用层与领域层业务处理  

3 返回结果并渲染UI层

由于前后端分离，UI层忽略不谈

 

 

应用层 

应用层和领域层以及基础设施层 完全不同于以往的service层和dao层

应用层是轻量级的，其往往用来处理

事务

安全认证

消息

对领域对象的操作 比如层资源库获取实体，然后调用领域对象执行相关业务

 

领域层

领域层完全聚集业务本身 但是不同于以往的service 

领域层业务处理的结果我们调用资源库层进行存储

 

资源库层

类似于dao层，用于封装不同的存储设备的客户端

进行实体的持久化

 

此外还有防腐层等辅助层

防腐层位于下游端消费上游服务，并将上游服务的领域对象转换到自己的领域

比如微信支付时，返回的结果是xml类型，且是微信系统的实体对象

系统需要加一层防腐层转化成当前支付上下文中支付结果值对象

 

 

如此可以知道

DDD并不是一项技术，确远远复杂于技术本身

上下文映射图如何建立

限界上下文是否合理

各领域对象是否被发现与建立

领域范围是否合适

如何转换为分层架构

如何用代码实践

这是一种值得开发者探索与分享的架构之路!

 

 

 

应用层举例:

控制事务

调用资源库获取聚合

交由领域对象执行业务

开发因尽量避免应用层过度复杂从而导致贫血模型

 

 

分层代码package

com.xxx.module.

                         interface []

                         application [协调领域层处理]

                         domain[领域层，聚焦业务逻辑处理]

                         infrastructure[包含dao,util等]

此外还要牢记面向抽象编程，依赖倒置原则等！

什么是依赖倒置:

高层模块不应该依赖于低层模块，两者都应该依赖于抽象

抽象不应该依赖于细节，细节依赖于抽象

上述即依赖倒置的模型，基础设施层可以实现其他所有层定义的接口

一般的实现为应用层和领域层