一、引言

领域驱动设计（Domain-Driven Design，简称DDD）作为一种软件开发方法论，其核心在于通过领域模型来指导软件设计和开发。从我初次接触DDD，到成功将旧系统改造为DDD模型，再到在三个项目中严格按照DDD规范进行开发，我经历了从疑惑到熟练的转变。现在，我将分享在这一过程中遇到的技术问题和解决方案。

1.1 从初学到实践

初学阶段：对DDD的基本概念和原则进行学习。- 旧系统改造：将现有系统按照DDD原则进行重构。- 项目落地：在三个项目中实现DDD规范。

1.2 技术实施成熟度

随着实践的深入，技术实施方面已经逐渐成熟，能够应对各种开发中的挑战。

1.3 知识分享

本文将分享团队在DDD落地实践中的技术点，而非理论部分。对于DDD的理论知识，推荐参考Eric Evans的《领域驱动设计》等专业书籍。

二、理论回顾

于DDD的理论基础，这里仅提供简要的提要。详细的理论知识，建议通过阅读相关书籍来获取。

2.1 DDD基础

领域模型：反映业务概念和业务逻辑的模型。- 统一语言：团队成员间共享的语言，用于沟通和设计。- 限界上下文：定义模型适用的范围。

2.2 推荐阅读

Eric Evans的《领域驱动设计》- 其他DDD相关理论书籍

2.3 注意事项

在本文中，将重点讨论技术实施而非理论基础。如果需要深入了解DDD，请参考上述推荐书籍。

请注意，本文内容是对DDD实践的技术分享，而非全面的理论教程。

2.1.1 名词

领域及划分：领域、子域、核心域、通用域、支撑域，限界上下文；

模型：聚合、聚合根、实体、值对象;

领域驱动设计（DDD）概念解析

领域驱动设计（DDD）是一种软件开发方法论，它强调以业务领域为中心进行系统设计。以下是对DDD中几个核心概念的详细解析：

实体（Entity）

实体是领域中唯一且可变的概念模型，由ID标识，具有生命周期和状态。状态通过值对象描述，而实体通过ID区分。例如，商品作为实体，其ID保持不变，即使商品数据发生变化。在DDD中，实体通常采用充血模型，将所有相关业务逻辑封装在实体类中。

聚合根（Aggregate Root）

聚合根是特殊的实体，作为聚合的根实体，具有全局唯一的ID。聚合根是聚合数据还原和保存的入口，确保数据的完整性。

聚合设计原则

聚合用于封装真正的不变性，而非简单的对象组合。2. 聚合应设计得尽可能小，以适应业务变化，减少重构需求。3. 聚合间的关联通过ID而非对象引用。4. 聚合内数据强一致性，聚合间数据最终一致性。

值对象（Value Object）

值对象的核心是其值，与数据类型复杂性无关。值对象无生命周期，通过值的一致性来区分。值对象应设计为只读，属性变化时需重建。

领域事件（Domain Event）

领域事件表示领域内发生的事件，触发进一步的业务操作。例如，支付完成后触发的事件可能引发订单生成和库存扣减。

事件处理原则

事件应包含ID、时间戳、类型和源等属性。- 事件为只读且不可变更。- 事件接收通常为异步，需考虑时序和重复发送问题。

聚合根、实体、值对象的区别

标识

聚合根：全局唯一标识。- 实体：聚合内唯一本地标识。- 值对象：无唯一标识。

只读性

聚合根：状态信息可变。- 实体：可变。- 值对象：只读。

生命周期

聚合根：独立生命周期。- 实体：生命周期从属于聚合根。- 值对象：无生命周期。

建模方法

在DDD建模过程中，应关注以下方面：

识别实体和聚合根：确定哪些概念模型是实体，哪些是聚合根。2. 设计值对象：创建只读的值对象，确保状态一致性。3. 定义领域事件：识别业务过程中的关键事件，并设计相应的领域事件。4. 应用聚合设计原则：遵循聚合设计原则，确保数据的强一致性和系统的灵活性。通过上述方法，可以构建一个以业务为中心，具有高度内聚和低耦合的系统模型。

事件风暴概述

事件风暴是一种类似头脑风暴的方法，其核心在于探索和定义领域内发生的事件、行动及其产生的影响。它是一个团队协作过程，涉及领域专家、设计师和开发人员共同参与。

1. 事件风暴的目的- 建立领域模型：通过事件风暴，团队成员可以共同构建一个反映业务流程和逻辑的模型。- 形成通用术语：确保团队成员使用一致的业务术语，以减少沟通误差。- 统一团队语言：通过讨论和共识，团队成员能够使用统一的语言来描述问题和解决方案。

2. 事件风暴的过程- 识别事件：确定在业务过程中发生的所有关键事件。- 分析行动：探讨每个事件背后的行动和决策过程。- 定义影响：明确每个事件对业务流程和结果的具体影响。

3. 事件风暴的成果- 形成用户故事：基于事件风暴的讨论，提炼出用户故事，为后续的开发工作提供指导。- 促进团队协作：通过共同参与事件风暴，增强团队成员之间的理解和协作。

4. 事件风暴的应用事件风暴不仅适用于软件开发项目，还可以应用于业务流程优化、产品规划等多个领域。

5. 注意事项- 保持开放性：鼓励团队成员自由表达观点，促进创新思维。- 记录讨论：确保所有讨论结果被记录和整理，以便后续参考。

6. 结语事件风暴是一个动态的、迭代的过程，它能够帮助团队深入理解业务需求，为项目的顺利进行打下坚实的基础。

在软件开发过程中，用户故事是一种重要的需求表达方式，它包括三个核心要素：角色、功能和价值。用户故事帮助团队明确谁需要使用功能、需要实现什么样的功能以及这个功能为何重要。例如，一个网站管理员可能希望统计每日访问量，以便向赞助商展示网站的价值。用户故事的分析有助于形成领域对象，这些对象对应于领域模型中的业务对象。每个业务对象和领域对象都有其特定的术语，并应保持一致性以确保概念的清晰。统一语言对于团队成员来说至关重要，尤其是在事件风暴和用户故事梳理过程中，随着讨论的深入，会出现许多专业术语。团队成员需要就这些术语达成共识，并建立一个名词字典，以统一后续的讨论和描述。这个字典可以采用Excel或在线文档的形式进行记录，并包含名称、描述、提取时间和参与人等信息。在代码模型设计阶段，需要确保领域对象与代码对象之间存在一一映射关系，以保证业务模型和代码模型的一致性。这有助于实现业务语言与代码语言的统一，从而提高开发效率和准确性。领域划分和建模是领域驱动设计（DDD）的核心。DDD的代码模型基于领域模型构建，确保每个代码模型的代码对象与领域对象相对应。通过UML类图、用例图和时序图等工具，可以完成软件模型的设计。在UML类图中，可以使用颜色来区分不同类型的对象，如聚合根、实体和值对象。

【 2.3 整洁架构（洋葱架构）】

** 整洁架构（Clean Architecture）是一种软件架构模式，由Bob大叔在2012年提出，旨在实现软件架构的清晰与简洁。其核心理念是依赖原则，即架构中各层的依赖关系应该由外向内，确保内层代码的独立性和高内聚性。以下是对整洁架构的详细解读和实践建议：

整洁架构概述

整洁架构强调代码的组织和分层，主要分为以下几层：

实体（Entities）：封装企业的核心业务规则，可以是对象或数据结构集合。- 用例（Use Cases）：包含应用特有的业务规则，实现系统用例的组合与编排。- 接口适配器（Interface Adapters）：负责数据格式的转换，连接用例和外部服务。- 框架与驱动（Frameworks and Drivers）：实现前端业务细节和基础设施，如UI和数据库。

依赖原则

整洁架构的依赖原则要求外层代码只能依赖内层，内层代码对外部一无所知。这有助于降低耦合度，提高代码的可维护性和可测试性。

实践建议

在DDD（领域驱动设计）的开发过程中，技术落地是关键。以下是一些实践建议：

内核与外壳分离：将业务逻辑集中在内核，而将基础设施和用户界面等非业务逻辑放在外壳。2. 充血模型：推荐使用充血模型来实现实体，使实体更加活跃，易于测试和维护。3. 持续迭代：在项目开发过程中，不断总结经验，优化架构。

工程示例

以Maven工程为例，展示内核与外壳分离的实践：

b2b-baseproject-kernel：内核模块，包含业务逻辑。- b2b-baseproject-center：中心服务模块，对外提供读写服务。

结语

走向DDD的道路多样，上述仅为一些实践方案。如有不足，欢迎指正和交流。

图3-1 kernel基础工程示例

内核Maven工程模块说明：

b2b-baseproject-center 实现模块说明

** **

图3-2 center基础工程示例

center Maven工程模块说明：

在软件开发中，内核与实现的分离是一种常见的架构设计模式。这种设计模式的采用，最初是由于商业化需求导致多版本开发的需求。然而，随着时间的推移，架构组逐渐倾向于推荐使用单一内核配合单一主版本实现的策略，以避免因多版本实现带来的分裂和维护成本的增加。以下是对这种设计模式的详细分析：

内核与实现分离的优点：

代码清晰性：内核与实现代码的完全隔离，使得内核更加干净和纯粹，便于理解和维护。2. 复用性：即便在不推荐多版本实现的情况下，如果需要支持多版本，内核可以被直接复用，减少了重复工作。3. 模块化：内核与实现的分离在一定程度上是一种更合理的分离方式，它确保了内核和实现版本各自关注核心问题，提高了模块化程度。

内核与实现分离的缺点：

联调成本：分离后的联调成本增加，每次改动后可能需要本地安装或推送到远程Maven仓库，增加了开发流程的复杂性。

应用场景建议：

对于大型项目，采用内核与实现分离的方式可以带来上述优点，但对于小型工程，考虑到开发和维护的简便性，建议直接在一个Maven工程中进行依赖开发。许多示例教程也推荐这种做法，因为它简化了开发流程。

结论：

内核与实现分离是一种有效的架构设计策略，尤其适用于需要高度模块化和可复用性的项目。然而，它也带来了一定的开发和维护成本。开发者应根据项目的具体需求和规模，权衡利弊后做出合适的选择。

CQRS（命令与查询职责分离）

CQRS 就是读写分离，读写分离的主要目的是为了提高查询性能，同时达到读、写解耦。而 DDD 和 CQRS 结合，可以分别对读和写建模。

在软件架构设计中，查询模型与命令模型是两种不同的数据模型，它们在处理数据时扮演着不同的角色。查询模型主要负责数据的查询和展示，而命令模型则负责执行具体的领域行为。以下是对这两种模型及其交互方式的详细解析：

查询模型与命令模型的基本概念

查询模型：这种模型专注于数据的查询和显示，它不直接参与到业务逻辑的处理中。- 命令模型：与查询模型不同，命令模型负责执行业务逻辑，处理领域行为。

命令模型通知查询模型的方式

共享数据源：如果查询模型和领域模型能够共享同一个数据源，那么命令模型在执行完毕后，查询模型可以直接获取到最新的数据状态。2. 发布订阅模式：当查询模型和领域模型不共享数据源时，可以采用发布订阅模式来实现数据的同步。命令模型在执行完毕后，通过发布消息来通知查询模型进行数据更新，以保持数据的最终一致性。

CQRS模式的适用性

Martin在博客中提到，CQRS（命令查询责任分离）模式适用于处理那些业务逻辑复杂且查询需求高的场景。如果业务逻辑较为简单，采用CQRS可能会增加系统的复杂度。- CQRS模式特别适用于需要高性能查询服务的业务场景。

读写分离架构模式

对于写入操作较少，而读取操作较多的共享数据服务，如主数据类应用，可以采用读写分离架构模式。- 在这种模式下，数据首先在单数据中心写入，然后通过发布订阅模式将数据副本分发到多个数据中心，实现数据的共享和查询。

领域模型与读模型的联系与差异

联系：领域模型和读模型都与业务领域相关，它们共同构成了业务系统的数据处理和展示。- 差异：领域模型更侧重于业务逻辑的处理，而读模型则侧重于数据的查询和展示。通过上述分析，我们可以看到查询模型和命令模型在软件架构中的重要性，以及它们如何通过不同的方式进行交互，以实现数据的一致性和系统的高性能。领域模型是业务逻辑的核心，它基于聚合根这一概念构建，聚合根是唯一入口点，负责业务数据的一致性和完整性。在这种模型中，如果将每个普通个体比作一个聚合根，那么该个体的身份证ID就相当于聚合根的主键，确保了其唯一性和识别性。聚合根具有自主性，意味着它们在接收到合理命令后能够独立进行属性变更，并主动将变更信息对外发布，从而保持业务流程的连贯性和一致性。视图层则类似于个体在社会中的投影，它反映了个体在某一时刻的教育、职业和健康状态等信息。视图是对领域模型的即时映射，但由于信息传播可能存在延迟，导致视图与领域模型之间可能存在时间差或不一致性。例如，当一个个体的健康状况发生变化时，相关的视图可能不会立即更新，从而造成信息的滞后或不同步。这种不一致性需要通过设计合理的信息传播机制来解决，以确保视图能够及时准确地反映领域模型的状态。

1. 你已经阳了，而你的健康码还是绿码;

在分布式系统中，确保数据的实时性和一致性是一个挑战。以下是对领域资源注册中心的背景分析和解决方案的详细描述：

背景分析- 领域模型独立性：领域模型通常不直接持有仓库或服务，保持了一定的独立性。- 内存验证局限：在进行数据验证时，领域模型只能依赖于内存中的数据，这限制了其能力。- RPC服务挑战：对于远程过程调用（RPC）服务，领域模型在进行数据验证时面临挑战。- 重复验证问题：在需要重复验证的场景下，领域模型的独立性导致效率问题。

解决方案- 领域模型注册中心：引入一个单例类作为领域模型注册中心，用以管理依赖的服务。- 服务的无状态性：注册中心中的服务必须是无状态的，以保证服务的可复用性和一致性。- 直接服务使用：领域模型可以直接使用注册中心中的服务，无需通过Spring框架的数据封装。

实践建议- 延迟和不一致的容忍：在业务处理中，应容忍一定程度的数据延迟和不一致性，以适应分布式系统的特性。- 消息传播优化：优化消息传播机制，以减少视图更新的延迟。- 更新时机控制：合理控制数据更新的时机，以减少不一致性。

通过上述措施，可以在保证系统效率的同时，尽可能地减少分布式系统中的数据不一致问题。

/**

在领域模型进行数据保存的时候，可用获取仓库或者验证服务进行数据验证。

/**

3.3.2 内核模块化的重要性

在主站服务中，由于面向的客户群体广泛，需求多样化，导致其功能和依赖服务的复杂性也随之增加。商业化部署时，通常只需要利用到总功能的一部分，大约10%到50%。如果部署时加载所有服务和领域模型，不仅需要配置相应的底层资源和依赖，还可能遇到启动异常的问题。为了解决这一问题，内核能力的模块化显得尤为关键。目前，我们主要采用Spring框架的条件加载机制来实现内核的模块化。具体实现方式如下：

条件加载机制：通过Spring的条件加载，我们可以在部署时根据实际需要，选择性地加载特定模块，从而减少资源消耗和依赖配置的复杂性。2. 模块化设计原则：在设计内核模块时，应遵循模块化的设计原则，确保每个模块的功能独立且清晰，便于管理和维护。3. 灵活配置：通过配置文件或环境变量，可以灵活地控制模块的加载与卸载，以适应不同的部署环境和业务需求。通过这种方式，我们能够实现内核模块的高效管理和灵活部署，确保主站服务的稳定性和可扩展性。

/**

这样在applicaiton.yml 配置相关能力的true/false, 就可以实现相关能力的按需加载，当然这是强依赖spring的基础能力情况下。

//appliciaton.yml 配置

在软件开发过程中，优化依赖关系是一个重要的议题。对于使用Spring框架的项目，可以通过条件加载来实现与Spring的解耦。具体来说，可以将Spring的装配逻辑单独抽取到一个Maven模块中，并利用这个模块作为starter，负责Spring相关的注入和适配工作。这种方式可以减少内核与Spring的直接依赖，从而提高项目的灵活性和可维护性。对于DDD（领域驱动设计）的实践，如果项目不受限于关系型数据库，开发者可能会更倾向于使用NoSQL数据库。NoSQL数据库支持事务，并且能够以聚合根为单位进行数据的整存整取，这可以显著降低持久化数据的开发工作量。然而，由于关系型数据库的普及，许多项目仍然需要处理复杂的数据库存储关系。在关系型数据库中，如果聚合根关联了多个实体，更新数据时可以选择整体覆盖的方式，即使数据行没有变化。为了提升性能，有时需要按需更新数据。这就需要一种机制来追踪实体对象的变更情况。实体对象的变更追踪可以通过以下两种方式实现：

方式一：可以使用特定的注解或装饰器模式来标记变更的实体，以便在更新时只处理这些变更的实体。
方式二：实现一个变更追踪系统，该系统能够在实体对象被修改时自动记录变更，从而在更新数据库时只提交变更的数据。这两种方式各有优势，可以根据项目的具体需求和团队的技术偏好来选择合适的实现方法。

A -&gt; 保存更新前快照，使用反射工具深度对比值是否变更；

在项目开发过程中，我们曾采用过两种不同的方案来处理实体的变更记录。 A方案：此方案的特点是代码侵入性较低，但需要在更新前保留完整的数据快照。在利用反射机制时，可能会对性能产生轻微的影响。 B方案：与A方案相比，B方案不需要保留更新前的数据快照，也无需使用反射。它要求在涉及数据变更的实体对象中增加一个RecordLog值对象，用以标记数据的状态，例如是新增、修改还是未变更。目前，我们主要采用的是B方案。在处理实体变更的入口方法时，我们会顺带调用RecordLog的更新方法。这样，在仓库层，我们可以通过RecordLog值对象的creating和updating属性来判断数据的状态，从而决定是执行新增操作还是更新操作。

/**

// 实体变更的时候，需要同步标记recordLog

/**

领域服务的读取设计

领域服务的构建不仅需要考虑数据的写入，更关键的是要实现数据的读取，以避免形成信息孤岛。读服务的设计面向视图，其核心需求是易于检索的数据结构、索引服务、宽表设计以及摘要信息的生成。重要的是，读服务不应修改原始数据，而是注重快速响应，无需进行数据锁定。

读服务的标准化

在领域服务设计中，内核可以提供一些标准化的读服务，这些服务通常围绕聚合根进行，例如通过聚合根的主键来检索基本的视图信息，或者进行列表检索。标准化的读服务为开发者提供了一个基础框架，但同时也允许根据具体需求进行个性化的查询参数和响应结果的设计和扩展。

读服务的实现

在b2b-baseproject-kernel工程的read-app模块中，定义了读服务的接口和返回对象的约束。而在center工程中，主要负责实现底层的读仓库和SDK接入层。这一层可以通过多种技术实现，如Elasticsearch（ES）、关系型数据库或Redis等，以提供底层的检索服务。

读服务接口设计

读服务的接口设计应考虑以下几点：

接口的通用性：确保接口能够满足大多数的查询需求。2. 参数的灵活性：允许开发者根据需求添加个性化的查询参数。3. 响应的定制性：根据查询结果定制响应格式，以适应不同的视图需求。通过这样的设计，读服务不仅能够提供快速的数据检索，还能够适应多变的业务需求，实现领域服务的高效和灵活。

/**

/**

/**

在分布式系统中，确保领域事件的可靠发布是一项重要任务。当不使用binlog或事务性消息组件时，本地事务表就成为了关键的解决方案。以下是实现这一目标的步骤和方法：

事务性记录：将领域对象的保存操作和领域事件的发布任务记录在一个本地事务中，确保它们要么同时成功，要么同时失败。
消息中间件（MQ）的使用：在数据库事务提交后，首先尝试通过消息中间件主动发送领域事件。这一步骤可以容忍发送失败。
失败重试机制：如果首次发送失败，系统将利用定时调度任务扫描事件表，寻找未成功发送的事件，并触发重发机制。
事件表的设计：事件表应设计为能够记录事件的发送状态，包括发送成功、失败或待重试等信息。
定时任务的设置：设置定时任务，周期性地检查事件表中的记录，并对未发送成功的事件进行重新发送。
容错性设计：整个系统的设计需要考虑到容错性，确保即使在部分组件失败的情况下，事件的最终一致性也能得到保障。通过上述步骤，我们能够构建一个不依赖于外部binlog或事务性消息组件的领域事件发布机制，同时保证了事件的可靠性和系统的健壮性。在软件开发中，领域事件的生成和处理是一个重要环节。以下是对领域事件生成和处理流程的说明：
领域事件的生成：领域事件通常在业务操作过程中产生。例如，当用户完成一次购买操作时，系统可能会生成一个订单创建事件。
事件的暂存：生成的领域事件首先会被暂存到一个注册中心。这样做的目的是为了在事务提交后再统一处理这些事件，保证数据的一致性。
事件的持久化：当事务提交时，系统会在一个事务包裹中将暂存的事件进行保存。这通常涉及到将事件信息写入数据库或其他持久化存储。
事件发布者：为了使聚合根能够使用事件发布服务，系统提供了一个发布者接口。聚合根需要实现这个接口，以便注册和发布事件。
内存管理：事件发布者内部使用WeakHashMap作为容器来存储注册的事件。这意味着，如果一个聚合根对象不再被使用，与之关联的事件列表将会自动被垃圾回收机制回收。通过这种方式，领域事件生成、暂存、持久化和发布过程被有效地组织和管理，确保了系统的健壮性和效率。

/**

在软件开发中，为了处理分布式系统中的数据一致性问题，我们通常会采用一些特定的事务处理模式。以下是对SAGA事务模式的详细解析：

1. 简化方案在某些情况下，如果应用不需要复杂的事件中转，可以简化消息处理流程。例如，使用Guava的EventBus组件，通过本地事件表的发送状态来作为任务处理状态。这种方法可以减少网络开销，并在应用内部实现消息发布-订阅机制。

2. SAGA事务概述在微服务架构中，传统的事务ACID原则难以保证跨服务的一致性。SAGA事务模式通过牺牲部分原子性和隔离性，采用补偿事务（Compensating Transaction）来实现最终一致性。

3. SAGA理论基础SAGA模式由Hector Garcia-Molina和Kenneth Salem在1987年提出，用于处理长活事务。它将长活事务分解为多个子事务，每个子事务都有相应的补偿操作，以保证数据的一致性。

4. SAGA的组成部分- 子事务（Sub-transaction）：每个子事务都是一个独立的事务，保证原子性提交。- 补偿操作（Compensation）：用于撤销子事务造成的影响，如果子事务只读或验证逻辑，可以为空。- 幂等性（Idempotency）：每个操作在分布式系统中应保证幂等，避免重复请求产生脏数据。

5. SAGA的执行顺序- 理想状态：子事务依次执行直至完成。- 向前恢复模式：在某个子事务失败时，执行补偿操作，撤销之前的操作。

6. SAGA的两种模式- 事件协同式（Event Choreography）：各参与方通过事件通信，自行管理决策和执行顺序。 - 优点：避免单点故障，简化开发。 - 缺点：可能存在循环依赖，难以追踪和维护。- 命令编排式（Order Orchestrator）：中央协调器控制所有参与者的执行顺序和时机。 - 优点：简化服务间关系，易于维护和扩展。 - 缺点：协调器可能变得复杂，存在单点故障风险。

7. 命令编排式SAGA示例以发票开票申请为例，SAGA协调器分为两个阶段：1. 协调器1负责参数验证、订单锁定等，发布子申请单创建事件。2. 协调器2在子申请单创建后，执行提票、开票等操作，并同步状态。

通过这种方式，SAGA事务模式能够有效地处理跨服务的数据一致性问题，同时保持系统的可维护性和扩展性。

文章目录