DDD领域驱动设计
Domain-Driven Design 简称DDD，是一种软件设计方法，它重点关注软件开发中设计领域的概念，旨在帮助团队在复杂系统中实现业务逻辑。
DDD的核心思想是将实现连接到持续进化的模型，通过领域模型驱动系统设计。
DDD的主要特点包括：
- 领域模型： 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质，领域是有边界的，只反映我们在领域内关注的部分
- 通用语言： 以一种领域专家，设计人员，开发人员都能理解的通用语言作为相互交流的工具
- 领域服务： 领域服务是领域提供的接口服务，需要定义在
domain.service包下，业务相关的前置业务判断，多个实体或值对象的行为逻辑处理等，都在领域服务中实现。
把一个复杂软件应用系统中各个部分进行很好的拆解和封装，对软件系统模块化的思想。
最终目标：高内聚，低耦合
限界上下文
限界上下文可以拆分为两个词，限界和上下文。限界是领域的边界，上下文是语义环境。限界上下文用于封装语言和领域对象，并提供上下文环境，保证领域之内的一些术语，业务相关对象有一个确切含义，无二义性。
聚合
实体和值对象是很基础的领域对象。实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。实体和值对象都只是个体化的对象，表现出的都是个体的能力。
聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑。
聚合根
如果把聚合比作组织，那么聚合根就是这个组织的管理者。聚合根也称为根实体。
作为实体本身，聚合根拥有实体的属性和业务行为，实现自身业务逻辑。
其次它作为聚合的管理者，在聚合内部负责协调实体和值对象按固定的业务规则完成共同的业务逻辑。
在聚合之间，聚合根还是聚合对外的接口人，以聚合根ID关联方式接收外部任务和请求，在上下文内实现聚合之间的业务协同。
聚合之间通过聚合根ID关联引用，如果要访问其它聚合实体，就要先访问聚合根，再导航到聚合内的实体。
领域事件
领域事件可以是业务流程的一个步骤，也可能是定时批处理过程中发生的事件。
在分析业务场景时，我们要捕捉业务，需求人员或领域专家口中的关键词：“如果发生…,则…”，”当做完…的时候，请通知….”
在这些场景中若发生某种事件后，会触发进一步操作，那么此事件很可能就是领域事件。
通过领域事件驱动的异步化机制，可以推动业务流程和数据在各个不同微服务之间的流转，实现微服务的解耦，减轻微服务之间服务调用的压力，提升用户体验。
一个完整的领域事件 = 事件发布 + 事件存储 + 事件分发 + 事件处理。
- 事件发布：构建一个事件，需要唯一标识，然后发布；
- 事件存储：发布事件前需要存储，因为接收后的事件也会存储，可用于重试或对账等；就是每次执行一次具体的操作时，把行为记录下来，执行持久化。
- 事件分发：服务内的应用服务或者领域服务直接发布给订阅者，服务外需要借助消息中间件，比如Kafka，RabbitMQ等，支持同步或者异步。
- 事件处理：先将事件存储，然后再处理。
当然了，实际开发中事件存储和事件处理不是必须的。
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以邮件至 1300452403@qq.com
