实践DDD领域驱动设计
说明
领域驱动设计最近又火了。概念不断被提及，但是相信对于像笔者一样的很多开发者对于其如何应用都一头雾水。
正如《实现领域驱动设计》中作者提到的不同公司的业务能力开发能力和成熟度不一样，DDD为了解决复杂业务为生，并不适合所有的软件项目，对于很多初创公司而言，业务本身就是模糊的，只是需要做出一个MVP(最小可行性产品)来试探商业模式，采用ddd显得过“重”了一点，反而给团队成员带来额外的负担，所以团队管理者首先应该关注的是软件系统是否值得做出DDD投入。
不过不管黑猫白猫，能抓到老鼠就是好猫。我们以电商业务来演练和实践ddd的部分理论，并解释ddd的概念。
战略设计阶段
领域：即业务是属于哪块，电商领域，保险领域，零售领域，又可细化分为子领域。如电商下（订单交易领域、库存领域、会员领域、物流领域....）
领域专家：一般指熟悉对应领域的产品经理项目经理
子域：子域可细分为核心子域、通用子域和支撑子域，简单理解为哪部分是比较核心的就可称作核心子域，哪些功能偏边缘化叫支撑域。
互联网公司的敏捷开发模式的产品研发流程从收集需求、PRD评审、技术模块拆分这些前期流程。而战略设计即在这个阶段完成，顾名思义侧重于从宏观上对业务进行拆分，和对未来走向的预测。
DDD的目的是为了领域专家更好地与开发进行沟通合作，使得代码更好地传达业务规则。
最初的需求方可能会提一些凌乱的需求。
为了更好地传达规则，领域专家将需求整合提取出领域的概念，技术/项目管理者一起划分好子域和限界上下文。各方统一所谓的通用语言并在以后的协作中使用。比如电商业务中双方约定好中商家用户和买家用户的概念，用户和账户的概念，交易订单和支付订单、物流订单、售后订单的概念，以实现后期沟通顺畅。
最终产出：划分出了哪些子领域、上下文映射图是怎样的。
贴一个电商业务的上下文映射图（下单交易上下文为下游，其他皆为上游）：
而各个上下文的交互方式，即集成限界上下文的方式其实就是我们常说的系统交互方式：RPC调用、REST接口调用、消息队列通信。
怎么理解限界上下文和子域的关系？
**限界上下文：**是一个显示边界，领域模型即存在于这个边界之内。在边界内，通用语言有特定明确的意义。
ps：是不是觉得每个字都认得，但是不知道表达了什么意思....
在理解限界上下文和子域上确实有点费劲。笔者当时的疑惑主要是：为什么要用上下文映射图而不是子域交互图，子域划分出来不就说明边界已经明确了么，为什么还专门搞一个限界上下文的概念。
关于限界上下文，贴一下个人理解：
接下来要咬文嚼字一些了。
1、从“限界”二字来说。限界上下文明确了业务范围和职责边界。针对上面问题“子域中不是已经有边界的概念了么”。可以思考一个有意思的事，子域有边界，还是说因为有了边界才有子域。听到过一个非常到位的类比：如果没有细胞壁，如何定义细胞质?
2、从“上下文”来说。上下文关注的是两个系统交互时的环境，或者说语境。
举个例子：小学是一个子域，中学是一个子域。升学这个事件动作则要上下文表达。
通用语言要在限界上下文（语境）中保证其明确意义。举个例子，商家管理上下文中，我们(平台)说的用户指的是商家而不是买家，支付上下文中，我们以支付单为核心，语境无需引入物流单、库存等词汇。
通常来说，我们可以近似地认为子域和限界上下文一一对应的。
战术设计阶段
截止到此，我们已经划分好了子域，对开发人员来说，已经拆分好了项目。各个团队可以针对自己的子域进行独立开发了。对于ddd而言，我们开始进行战术设计阶段。战略设计关心做什么，战术设计则更关心技术实现细节，即：怎么做。
先说下ddd中推荐的六边形架构：
这里要吐槽一下六边形架构这个命名，搞得好像有六个什么东西一样。其实只是根据视觉形状起的名。现在叫端口与适配器架构。
转换一下是这样的
**严格分层架构：**某层只能与直接位于其下方的层发生耦合
**松散分层架构：**允许上方层可以与任意下方层发生耦合。
这里采用松散分层架构。也可按依赖倒置原则, 基础层依赖领域层的一些东西（常见的就是实体Entity）
适配器层：
负责接口转换，即是最外层请求处理类，将外部请求转化为内部API能理解的输入。对于REST接口可能是一个controller类；
对于dubbo调用来说是开放出去的provider服务类；
对于grpc调用来说，是protobuf请求对象转换处理类；
对于消息机制来说，对应的是消息的监听器
如此采用端口适配器模式，可以不影响内部服务，只需在适配器层进行增改。尽管大家不知道六边形架构的定义，但相信很多人是这样做的。无须赘述。
应用层：负责协调领域层的接口实现前端展示或返回需要。
领域层：定义领域实体和逻辑。包括实体、值对象、领域服务、领域事件、资源库。
基础层：如数据库相关。
实体和值对象
实体：
有唯一业务标识
有自己的业务属性和行为
属性可变，有自己的生命周期
值对象：
可以有唯一业务标识
有自己的业务属性和行为
一旦定义不可改变
二者的关系可总结为：值对象关心对象是什么样的，实体侧重描述对象是哪个？
提到有自己的业务属性和行为这块，想想这不就是我们年轻时说的面向对象编程的思想码？
但是回顾一下会发现，这个思想好像被很多人抛诸脑后很久了，定义的对象类都成了一个个的pojo，只有属性和属性对应getter和seter方法，也就是ddd中所说的失血模型。
**失血模型：**只含属性和对应的getter/setter方法，无业务处理逻辑
贫血模型：包含不依赖持久化的部分领域逻辑，依赖持久的逻辑被放在领域服务层。
充血模型：绝大数业务逻辑都放在其中，包括持久化逻辑。少数不适合的逻辑被提取出来放在领域服务层中。
胀血模型：主张不需要领域服务层，把一些业务逻辑都放在模型对象中处理
领域服务
胀血模型主张把所有的业务逻辑放在模型中处理，但是事实上有些逻辑并不是适合放在某个领域对象中处理。比如
1、领域对象间的转换
2、某些场景下需要多个领域对象作为输入值，结果产生一个值对象。
区别于应用层的服务，领域服务处理的是业务逻辑。应用层负责对领域服务处理结果进行渲染和组装返回给前端。ps: 针对查询类的操作，建议作为应用层的查询服务单独拎出来，因为查询尝尝涉及到多个维度的查询，或把多个领域对象的查询结果组装成一个返回值对象。
举个栗子：订单领域需要向商家（PC端）和买家（APP端），商家端按发货条件时间查询所有买家的订单，操作发货处理售后等流程。买家端完成下单、查询个人订单。在应用层我们抽象三个应用处理出来，公用的查询应用、商家端应用（关联商家权限控制上下文）、买家端应用（关联买家权限控制上下文）。
领域事件
领域事件即领域业务周期中一些关键行为，关键的定义是其他地方需要依赖此事件推送业务流转。如订单被支付这个事件，需要触发库存扣减、商家待结算账户余额增加等操作。关于领域事件处理方法：跨子域处理常用消息队列发布/订阅模式，同项目处理常用注册事件监听器处理。不多描述。
聚合和资源库
领域对象之间常常有依赖关系。比如主订单-子订单(商品)项，子订单依附于主订单存在，二者的关系称作聚合，主订单作为聚合根。
@Data
public class TradeOrderEntity {
//订单号
String orderNo;
// 商品详情
List<OrderItemDetailEntity> orderItemDetails;
我们通过为每一个聚合选择一个根，并通过根来控制所有对边界内的对象的访问。外部对象只能持有根的引用；由于根控制了访问，因此我们无法绕过它去修改内部元素。所以在ddd中，资源库Repository是面向聚合根操作的,可对多个dao对象的组合使用。
@Repository
public class TradeOrderRepository {
@Autowired
TradeOrderMapper tradeOrderMapper;
@Autowired
OrderItemDetailMapper orderItemDetailMapper;
}
关于其中一些思想，笔者也没有想清楚，所谓知行合一，恐怕很多方法论要真的遇到问题了才会理解其价值。先整理到这。最后针对Java后端开发同学，提供一个模块分层的框架供参考
思考
无忌，我教你的还记得多少？” “回太师傅，我只记得一大半”
“ 那，现在呢？” “已经剩下一小半了”
“那，现在呢？” “我已经把所有的全忘记了！”
“好，你可以上了…”
