DDD基本介绍！

为什么需要DDD

复杂系统设计：

• 系统多，业务逻辑复杂，概念不清晰，需要合适的方法帮助我们理清楚边界，逻辑和概念。

多团队协同：

• 边界不清晰，系统依赖复杂，语言不统一导致沟通和理解困难。
• 需要一种方式把业务和技术概念统一，大家用一种语言沟通。

设计与实现一致性：

• PRD，详细设计和代码实现天差万别，需要一种方法可以把业务需求快速转换为设计，同时还要保持设计与代码的一致性。

架构统一，可复用资产和扩展性：

• 当前取决于开发的同学具备很好的抽象能力和高编程的技能，需要好的方法指导我们做抽象和实现。

DDD的价值

边界清晰的设计方法：

• 通过领域划分，识别哪些需求应该在哪些领域，不断拉齐团队对需求的认知，分而治之，控制规模。

统一语言：

• 团队在有边界的上下文中有意识地形成对事物进行统一的描述，形成统一的概念(模型)。

业务领域的知识沉淀：

• 通过反复论证和提炼模型，使得模型必须与业务的真实世界保持一致，促使知识(模型)可以很好地传递和维护。

面向业务建模：

• 领域模型与数据模型分离，业务复杂度和技术复杂度分离。

为什么DDD适合微服务？

微服务拆分困境产生的根本原因就是不知道业务或者微服务的边界到底在什么地方

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

DDD 不是架构，而是一种架构设计方法论，通过边界划分将复杂业务领域简单化，设计出清晰的领域和应用边界。

DDD与微服务的关系

DDD：

• 从业务领域视角划分领域边界，构建通用语言进行高效沟通。
• 通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

微服务：

• 运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理。
• 关注微服务的独立开发、测试、构建和部署。

如何划分领域模型和微服务的边界

第一步：

• 在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等。
• 根据这些要素梳理出领域实体等领域对象。

第二步：

• 根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。

第三步：

• 根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。
• 不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离。

DDD领域的领域建模方法

第一步:

• 将领域分解为子域，子域可以分为核心域、通用域和支撑域。

第二步:

• 对子域建模，划分领域边界，建立领域模型和限界上下文。

第三步:

• 根据限界上下文进行微服务设计。

如何用事件风暴构建领域模型？

领域建模的过程主要包括产品愿景、业务场景分析、领域建模和微服务拆分与设计这几个重要阶段。

产品愿景：

• 对产品顶层价值的设计，使产品目标用户、核心价值、差异化竞争点等信息达成一致，避免产品偏离方向。

业务场景分析：

• 从用户视角出发的，根据业务流程或用户旅程，采用用例和场景分析，探索领域中的典型场景。
• 找出领域事件、实体和命令等领域对象，支撑领域建模。
• 事件风暴参与者要尽可能地遍历所有业务细节，充分发表意见，不要遗漏业务要点。

领域建模：

• 领域建模时，会根据场景分析过程中产生的领域对象，比如命令、事件等之间关系，找出产生命令的实体。
• 分析实体之间的依赖关系组成聚合，为聚合划定限界上下文，建立领域模型以及模型之间的依赖。
• 领域模型利用限界上下文向上可以指导微服务设计，通过聚合向下可以指导聚合根、实体和值对象的设计。

微服务拆分与设计：

• 原则上一个领域模型就可以设计为一个微服务。