文章目录

• 一、领域驱动设计概念

• 1、基本概念

• （1）通用语言

• （2）领域设计4层模型

• （3）DDD适合的场景

• 2、领域、子域、界限上下文

• 3、核心子域、支撑子域、通用子域

• 4、界限上下文的关系

• 5、领域模型的要素 - 实体、值对象、聚合

• （1）实体

• （2）值对象（Value Object）

• （3）聚合（Aggregate）

• （4）案例分析

• 6、构建领域模型 - 工厂、库、领域服务

• （1）工厂（Factory）

• （2）资源库（Repository）

• （3）领域服务（Domain Service）

• 7、反腐层

• 二、领域建模方法论

• 1、企业架构法

• 2、面向服务设计法（SOA）

• 3、用例分析法

• 4、四色建模法

• 5、初识Event Storming事件风暴

• 6、领域模型的选择 - 贫血、充血模型

• 7、洋葱圈模型

• 三、领域事件

• 1、初识领域事件Domain Event

• 2、领域事件，代码实例

• （1）生产者发布事件

• （2）消费者订阅事件

• （3）EventStore做事件存储

• （4）定时任务轮询投递事件

• 3、领域事件与CQRS

• （1）什么是CQRS

• （2）CQRS和ES事件溯源

• 四、案例：敏捷项目管理系统

• 1、功能分析

• 2、子域划分

• 3、定义实体、值对象、聚合

• （1）聚合根

• （2）值对象

• （3）实体

• （4）聚合

• 4、落地工厂、库、领域服务

• （1）工厂

• （2）资源库

• （3）领域服务

• 5、落地反腐层

• （1）完整图示

• （2）领域服务

• （3）适配器：进行适配+调用上有服务

• 6、应用服务

• 7、建模的核心要素 - 隐性的概念显性化

• 8、规则选择 - 策略模式

• 9、规则拼装 - 组合模式

• 10、事件风暴 - Event Storming

• （1）事件Event

• （2）痛点/问题/关键点（IDEAS, RISKS）

• （3）命令Command

• （4）聚合Aggregate

• （5）外部系统External System

• （6）第一阶段成果

• （7）构建微服务间关联关系

• （8）形成类图

• （9）事件风暴核心思想

• 10、DDD模型下的代码分层模型

• 五、案例：电商场景领域模型设计

• 1、子域

• 2、上下文

• 参考资料

一、领域驱动设计概念

1、基本概念

（1）通用语言

领域驱动设计，作为一个技术、产品、用户通用的语言进行沟通，极大地降低了沟通成本与沟通失真问题。

（2）领域设计4层模型

领域驱动设计（DDD）适用场景

领域驱动设计（DDD）是一种以产品业务逻辑为核心的设计方法，它不以用户界面或数据结构为主导。DDD适用于中大型项目，特别是在API经济和中台化架构中，可以利用DDD对微服务进行有效拆分。

1. 领域、子域和界限上下文的概念

领域（Domain）：指一个独立的业务领域，具备在市场中独立盈利的能力。例如，二手车交易、电子商务、宠物寄养服务等。 子域（SubDomain）：领域可以细分为多个子域，每个子域针对一个更具体的业务范围或问题域。例如，支付、商品管理、用户认证等。 界限上下文（Context）：上下文是解决子域问题的特定环境。例如，支付上下文、用户认证上下文等。 子域定义了问题空间，而界限上下文则提供了解决方案的空间。

2. 子域的分类

子域可以进一步分为以下几类：

• 核心子域：对业务至关重要的子域，通常具有较高的业务价值和复杂性。- 支撑子域：对核心子域提供支持，但相对独立，可以单独优化和改进。- 通用子域：在多个领域中普遍存在，可以跨领域复用的子域。 通过DDD的视角，我们可以更清晰地识别和划分业务领域，为微服务的拆分和架构设计提供指导。
  

核心域与支撑子域概述

核心域核心域是指构成某一领域核心功能的集合。在电商平台中，核心域包括但不限于以下几个方面：

产品信息核心域- 产品展示- 产品分类- 产品详情

支付交易核心域- 交易流程- 支付方式- 订单管理

物流域- 物流跟踪- 配送设置- 库存管理

支撑子域支撑子域是辅助核心域正常运作的子系统。以下是一些常见的支撑子域：

用户行为分析域- 用户行为追踪- 数据分析- 用户画像构建

风控域- 风险识别- 风险预防- 风险处理

通用子域通用子域是指在不同领域内普遍适用的子系统。例如：

用户认证系统- 第三方登录- 账号管理- 安全认证

界限上下文的关系界限上下文是指各个核心域和子域之间的边界及其交互方式。它们之间的关系通常包括：

1. 核心域之间的协作：核心域之间需要通过定义清晰的接口和协议来实现数据和功能的交互。2. 支撑子域对核心域的支持：支撑子域通过提供特定的服务或数据，增强核心域的功能。3. 通用子域的跨领域应用：通用子域可以被多个核心域或支撑子域调用，实现资源共享。 通过明确界限上下文，可以确保系统的模块化和可扩展性，同时也便于管理和维护。
   
   在微服务架构中，界限上下文是定义服务边界的关键概念。以下是对界限上下文及其相关概念的梳理：

界限上下文与子域功能

界限上下文代表了一个子域的功能范围。它定义了服务的边界，确保服务的独立性和可维护性。

上游与下游

• 上游（U-upstream）：提供服务的一方。- 下游（D-downstream）：接收服务的一方。

关系类型

1. Conformist：跟随者关系，本系统必须与某个上游系统绑定，但以对方为主。2. ACL（Anticorruption Layer）：反腐层，用于与遗留系统集成，通过适配器层转换模型。3. Partnership：合作伙伴关系，服务之间有更紧密的合作。4. Shared Kernel：共享内核，服务之间共享代码模型和组件。5. Separate Ways：分离模式，两个微服务之间没有联系。6. Customer Supplier Teams：客户供应者模式，上下游系统有强依赖关系，需要快速响应模型逻辑的修改。7. Single Bounded Context：合并上下文模式，两个服务紧密到无法分开，共享所有模式要素。

领域模型的要素

实体（Entity）

• 具有唯一标识，可以由用户提供、应用生成UUID/GUID或由持久化系统生成。- 数据可变，需要生命周期管理，如订单状态的变更。

值对象（Value Object）

• 没有唯一标识，数据不可变，可以复制和替代。- 体现整体性，如货币金额或地址。

聚合（Aggregate）

• 作为事务一致性边界，保证数据和行为的一致性。- 聚合之间通过聚合根进行通信。- 应尽量缩小聚合范围，以简化事务复杂度。

案例分析

（此处应根据具体案例进行分析，但根据要求，将示例文本替换为 ） 以上是对界限上下文及其在微服务架构中的作用和相关概念的详细解释。

在软件架构设计中，领域模型的构建是核心环节之一，它直接影响到系统的功能实现和维护。以下是对领域模型构建的详细解读：

1. 工厂（Factory）工厂模式是一种创建对象的设计模式，它能够将对象的创建逻辑封装起来，从而实现对象创建的解耦。工厂模式可以采用工厂类、工厂方法或抽象工厂模式来实现。它主要作用是：

• 创建聚合和实体：简化对象的创建过程，隐藏创建逻辑。- 封装复杂操作：将对象创建过程中的复杂步骤封装起来，提高代码的可维护性。

2. 资源库（Repository）资源库模式是用于数据访问的模式，它提供了对聚合数据的增删改查操作。资源库模式的特点包括：

• 实现数据操作：提供统一的数据访问接口。- 对接持久化机制：如Hibernate等，实现数据的持久化存储。- 封装复杂操作：简化数据访问逻辑，提高代码的可读性和可维护性。

3. 领域服务（Domain Service）领域服务是处理领域逻辑的服务组件，它的特点如下：

• 无状态：领域服务通常不持有状态信息。- 业务操作：处理不属于实体和值对象的业务逻辑。- 转换处理：如密码加密、文字转换等，实现领域对象之间的转换。

4. 反腐层（Anti-corruption Layer, ACL）反腐层是新旧系统之间交互的缓冲区，它的主要作用是：

• 隔离新旧系统：确保新系统设计不受旧系统限制。- 转换机制：在不同系统间转换数据和概念。- 保护系统：避免异常代码的侵入，维护系统的稳定性。- 域映射：将一个域的概念映射到另一个域，保持概念的独立性。 构建领域模型时，应充分考虑这些模式的应用，以实现系统的高内聚、低耦合，并确保系统的可扩展性和可维护性。
  

二、领域建模方法论

1、企业架构法

2、面向服务设计法（SOA）

3、用例分析法

4、四色建模法

红色：时标型（Moment-Interval）对象。

绿色：PPT（Party/Place/Thing）对象。

黄色：角色（Role）对象。

蓝色：描述（Description）对象。

5、初识Event Storming事件风暴

演进式架构和迭代式开发。
微服务拆分和向前兼容。
如何和产品业务人员沟通。
有没有一个可以在喝茶聊天中完成微服务拆分的方法？

在软件设计领域，领域模型的选择对于应用的架构和业务逻辑的实现至关重要。领域模型主要分为两种类型：贫血模型和充血模型。它们各自代表了不同的设计理念和适用场景。

领域模型概述

贫血模型- 定义：贫血模型中，领域对象主要包含数据和简单的getter/setter方法，而核心业务逻辑则位于服务层或更上层。- 优势：易于上手，开发速度快，适合于业务逻辑相对简单，以数据记录为主的应用场景。- 局限：随着业务逻辑的复杂化，维护和扩展性可能受限。

充血模型- 定义：充血模型更贴近领域驱动设计的理念，强调领域对象的业务逻辑，get/set方法通常是私有的，对外提供丰富的行为方法。- 优势：具有更高的灵活性和扩展性，适用于业务逻辑复杂，需要高度封装和信息处理的应用。- 适用场景：三高（高可用性、高性能、高扩展性）项目。

洋葱圈模型- 概念：洋葱圈模型是一种软件架构模式，通过层次化的方式组织代码，每一层都有其特定的职责，从而实现代码的高内聚和低耦合。

总结选择领域模型时，需要根据项目的具体需求和特点来决定。贫血模型适合快速开发和简单应用，而充血模型则适用于需要复杂业务逻辑处理的项目。洋葱圈模型则提供了一种有效的架构设计方法，帮助开发者构建清晰、可维护的代码结构。

三、领域事件

1、初识领域事件Domain Event

异步通信，符合事件驱动风格。

通常用消息队列（MQ），可以实现削峰填谷。

但是要处理消息丢失、消息重复的问题。

2、领域事件，代码实例

（1）生产者发布事件

（2）消费者订阅事件

（3）EventStore做事件存储

（4）定时任务轮询投递事件

领域事件与CQRS概述

1. CQRS定义CQRS（Command Query Responsibility Separation）是一种软件架构模式，它将读（Query）和写（Command）操作的职责分离。这种分离有助于提高系统的性能和可扩展性。

2. CQRS组件- Command：执行动作的命令，通常返回void。这类操作可能会改变聚合、实体或值对象的状态。- Query：只负责查询数据，不涉及任何修改操作。

3. CQRS适用风格- 事件驱动系统风格：以事件作为数据流转的核心。- 管道过滤器风格：数据在多个处理阶段中流转，每个阶段只处理部分数据。

4. CQRS与ES的结合- 普通CQRS：主要处理数据的增删改查操作，但不支持数据的溯源。- CQRS与ES结合：ES（事件溯源）提供了一种机制，可以追踪和重放系统中发生的所有事件，从而实现数据的可溯源性。

5. 事件溯源（Event Sourcing）事件溯源是一种将应用程序状态变化存储为一系列事件的模式。这些事件可以用于重建状态，也可以用于审计和调试。

6. 结合CQRS和ES的优势- 增强了系统的可维护性和可测试性。- 通过事件驱动的方式，可以更容易地实现分布式系统。- 事件的持久化和重放能力，为系统的可追溯性和一致性提供了保障。

结论CQRS和ES的结合为构建可扩展、可维护的复杂系统提供了一种有效的架构模式。通过分离读写操作和利用事件驱动的方法，可以提高系统的响应速度和数据处理能力。同时，事件溯源机制确保了数据的完整性和可追溯性。

事件溯源：数据只做增和查，可以做到事件溯源。

四、案例：敏捷项目管理系统

1、功能分析

项目管理系统，涉及项目发布、代办、状态、任务等等。

2、子域划分

3、定义实体、值对象、聚合

（1）聚合根

领域驱动设计中，对外提供功能的只有聚合根的功能，聚合根里面的实体尽量只对聚合根提供服务。

聚合根的子对象，尽量都用实体对象封装。

（2）值对象

值对象不提供独有的ID，全部通过快速复制快速创建，永不修改来实现这些值对象的描述性的信息。

（3）实体

把子对象用实体的形式进行封装，成员变量private，set和get方法private，让它们更加生动的操作protected，让其他成员来访问。，聚合根里面的实体尽量只对聚合根提供服务。

（4）聚合

把聚合根、值对象、实体打包起来，就形成了聚合。

4、落地工厂、库、领域服务

（1）工厂

（2）资源库

（3）领域服务

5、落地反腐层

（1）完整图示

（2）领域服务

（3）适配器：进行适配+调用上有服务

6、应用服务

应用服务的方法与工厂、资源库之间的关联：

7、建模的核心要素 - 隐性的概念显性化

隐性的概念显性化：多种不同的逻辑封装到一起，按情况进行处理。

隐形的上下文显性化。

封装多对象行为。

8、规则选择 - 策略模式

9、规则拼装 - 组合模式

事件风暴 - Event Storming

1. 事件（Event）

• 定义：事件是业务领域中已经发生的、对系统产生业务影响的事实。
• 特点：通常不包括数据查询等仅对系统产生技术影响的操作。
• 表示方法：使用正方形橘黄色便利贴，并采用过去时态，例如：用户已注册（User Registered），激活邮件已发送（ActivationEmail Sended）。

2. 痛点/问题/关键点（IDEAS, RISKS）

• 表示：用红色便利贴标记，表示需要特别注意或存在不确定性和风险的点。
• 位置：通常贴在相关事件旁边。

3. 命令（Command）

• 关系：命令是产生事件的动作，与事件一一对应。
• 示例：与用户已注册（User Registered）事件对应的命令是注册用户（Register User）。
• 表示方法：使用正方形蓝色便利贴，将事件表述“反过来”。

4. 聚合（Aggregate）

• 定义：指某个Actor在某个聚合上调用命令产生事件的过程。
• 示例：普通用户（Normal User）在注册表（Register）上调用注册用户（Register User）命令产生用户已注册（User Registered）事件。
• 表示方法：使用紫色即时贴。

5. 外部系统（External System）

• 作用：事件可能由外部系统或规则自动触发命令产生，而不仅仅是由Actor触发。
• 表示方法：使用绿色即时贴。

6. 第一阶段成果

• 此部分内容需根据具体事件风暴过程的成果来填写，此处暂留空。
  

（7）构建微服务间关联关系

（8）形成类图

事件风暴的核心理念

1. 由下而上的快速启动与常规的自上而下的模块拆分不同，事件风暴采用自下而上的方法，从具体的事件出发，快速启动项目，提高效率。

2. 事件驱动的灵活性事件风暴以事件为核心，架构设计围绕事件进行，便于在用户体验变化时，快速调整和更新相关聚合。

3. 促进团队协作通过在白纸上记录和讨论，事件风暴促进了团队成员之间的沟通，帮助团队成员达成共识，实现服务的高效拆分。

---

DDD模型下的代码分层架构

1. 概述DDD（领域驱动设计）模型强调以领域为中心的软件开发方法，其代码分层模型是实现这一方法的关键。

2. 分层架构DDD模型下的代码分层通常包括以下几个层次：- 领域层：定义业务逻辑和业务规则。- 应用层：协调领域层与基础设施层的交互。- 基础设施层：提供技术实现，如数据库访问、消息传递等。

3. 各层作用- 领域层：是DDD的核心，负责业务逻辑的实现。- 应用层：作为领域层与外部世界的桥梁，处理应用程序的用例。- 基础设施层：为应用层提供必要的技术支撑。

4. 优势DDD模型的分层架构有助于清晰地划分系统的不同部分，提高代码的可维护性和可扩展性。

DDD实践：电商场景领域模型设计

一、子域划分

电商系统可以划分为多个子域，以反映业务的不同方面和复杂性。以下是电商系统的主要子域和支撑子域：

核心子域- 买家- 支付- 履约- 卖家- 市场- 用户- 风控- 客服- 搜索- 财务- 产品- 定价- 认证- 内部- 推荐- 社交- 合作- 库存

通用和支撑子域- 数据平台- 数据科学- 负载管理- 内容管理- 消息通告- 安全加固- 基础架构- 应用平台- 质量保证- 集成发布- 遥测监控- 合规审计

二、上下文定义上下文是领域驱动设计中的一个重要概念，它定义了不同模型和实体的边界。以下是电商系统中的一些关键上下文：

认证上下文- 注册认证- 用户登录- 访客登录- 内部登录- 身份验证- 令牌管理

用户上下文- 用户联系- 用户服务- 用户设备- 用户喜好- 用户背调- 用户支付- 用户行为- 用户设置- 用户订单- 用户发布- 用户折扣- 会籍管理

市场上下文- 折扣策略- 优惠券- 促销管理- 用户粘性- SEO- SEM

搜索上下文- 公共搜索- 个人搜索- 信息编目

客服上下文- 语音客服- 机器人- 客户关系

买家支付上下文- 支付方式- 支付网关- 支付交易- 保险

卖家支付上下文- 支付方式- 支付网关- 支付交易- 税务

履约上下文- 卖家履约- 买家验收- 物流

风控上下文- 风控模型- 支付风险- 账户风险- 交易风险

推荐上下文- 个性推荐- 趋势推荐- 广告推荐

定价上下文- 价格限制- 价格推荐- 费用计算

买家上下文- 下单- 订单- 购物车- 跨境交易

卖家上下文- 发布管理- 一手平台- 二手平台- 订单

财务上下文- 子账- 收入- 利润- 税收- 对账- 应收应付

三、设计原则在设计电商系统的领域模型时，应遵循以下原则：- 高内聚，低耦合：确保每个子域的职责清晰，减少子域间的依赖。- 模型一致性：保持领域模型的一致性，避免概念上的混淆。- 可扩展性：设计时考虑系统的未来发展，确保模型的可扩展性。- 用户中心设计：以用户需求为中心，确保系统设计满足用户的实际需求。

四、实施步骤1. 领域分析：深入理解业务需求，识别核心领域和子域。2. 上下文映射：明确不同上下文的边界和交互方式。3. 实体和聚合设计：设计领域实体和聚合，定义它们的关系和行为。4. 领域服务实现：实现领域逻辑，包括业务规则和流程。5. 集成和测试：集成各个子域，进行全面测试以确保系统的正确性和稳定性。

五、案例分析参考DDD堵崔饮践撕Event Storming中的案例，分析如何将DDD应用于电商系统的设计中。