DDD中一些专业名词的理解

子域

粗领域边界的划分,不考虑子域内的领域对象、对象之间的关系和结构,按照业务阶段或者功能模块边界进行粗分.

(业务的划分)

界限上下文

本质上也是子域. 设计出了领域模型，明确了领域对象以及领域对象的依赖等关系，有了领域模型.

(技术上的划分)

核心域 通用域 支撑域

核心域、通用域和支撑域都是业务领域，只不过重要性和功能属性不一样。采用的 DDD 设计方法和过程，是没有差异的。

领域事件

在对数据一致性要求比较高的业务场景,也就是发送方和订阅方的事件数据都必须落库，发送方除了保存业务数据以外，在往消息中间件发布消息之前，会先将要发布的消息写入本地库。而接收方在处理消息之前，需要先将收到的消息写入本地库。然后可以采用定期对发布方和订阅方的事件数据对账的操作，识别出不一致的数据。如果数据出现异常或不一致的情况，可以启动定时程序再次发送，必要时可以转人工操作处理。

逻辑边界

微服务内聚合之间的边界是逻辑边界。它是一个虚拟的边界，强调业务的内聚，可根据需要变成物理边界，也就是说聚合也可以独立为微服务

物理边界

微服务之间的边界是物理边界。它强调微服务部署和运行的隔离，关注微服务的服务调用、容错和运行等

代码边界

不同层或者聚合之间代码目录的边界是代码边界。它强调的是代码之间的隔离，方便架构演进时代码的重组

通过以上边界，我们可以让业务能力高内聚、代码松耦合，且清晰的边界，可以快速实现微服务代码的拆分和组合，轻松实现微服务架构演进。但有一点一定要格外注意，边界清晰的微服务，不是大单体向小单体的演进。