DDD架构模式全解析：从分层到微服务的实战演进

1. 项目概述：从“战术混乱”到“战略清晰”的架构演进

在软件开发的江湖里，我们常常会陷入一种“战术勤奋，战略懒惰”的困境。团队里每个人都很忙，代码量蹭蹭上涨，新功能也能按时交付，但系统内部却像一团不断缠绕的毛线球，业务逻辑散落在各个角落，一个简单的需求变更需要修改五六个地方，牵一发而动全身。这种时候，我们需要的不是更快的编码速度，而是一套能从根本上理清业务复杂度、让代码结构反映业务本质的方法论。领域驱动设计（Domain-Driven Design， DDD）正是为此而生，它不仅仅是一种编程范式，更是一套完整的、以领域为核心的软件设计哲学。

然而，很多团队在初次接触DDD时，往往会被其丰富的概念所淹没：实体、值对象、聚合、仓储、领域服务、应用服务……这些“战术”层面的构建块固然重要，但如果没有一个清晰的“战略”架构将它们有机地组织起来，最终得到的可能只是一个披着DDD外衣的、更加复杂的“大泥球”。架构，就是将这些战术组件进行战略部署的蓝图。它决定了不同职责的代码应该放在哪里，它们之间如何交互，以及如何应对变化。

今天，我们就来深入聊聊DDD实践中几种典型的架构模式。这不仅仅是理论介绍，更是我过去几年在多个中大型复杂业务系统中，从踩坑到填坑，最终让DDD真正落地、发挥价值的经验总结。你会发现，没有一种架构是银弹，每种架构都有其特定的适用场景、优势和需要警惕的“坑”。理解它们，是为了在面对具体业务时，能做出最合适的选择，构建出既健壮又灵活的系统。

2. 经典分层架构：DDD的入门基石与清晰边界

当我们谈论DDD架构时，最常被提及的起点就是经典的四层架构。它像一座结构清晰的大厦，将不同的关注点严格分离，是理解DDD代码组织方式的基础。

2.1 四层结构解析：各司其职的精密协作

经典四层架构从上至下通常包括：用户界面层（User Interface Layer）、应用层（Application Layer）、领域层（Domain Layer）和基础设施层（Infrastructure Layer）。每一层都有其不可替代的职责和明确的协作规则。

用户界面层：这是系统与外部世界（用户、其他系统）交互的边界。它的职责是处理输入（如HTTP请求、命令行参数、消息队列事件）和输出（如HTML页面、JSON响应、事件发布）。这一层应该尽可能“薄”，它不包含任何业务逻辑，只负责数据的展示、收集和协议转换。例如，一个RESTful API的Controller，它的工作就是验证输入DTO的格式，调用应用层的服务，然后将应用层返回的结果组装成响应DTO。我见过很多项目把参数校验、权限判断等业务规则写在这里，这会导致相同的规则在多个入口点重复，且难以测试。

应用层：这是协调者或指挥家。它不包含核心业务规则，但负责协调领域对象来完成一个特定的用例（User Case）或应用服务。一个应用服务方法通常对应一个用户操作，比如“创建订单”、“支付订单”。它的典型工作流是：从UI层接收指令，通过仓储（Repository）加载聚合根，调用聚合根或领域服务的方法执行业务操作，最后通过仓储持久化变更，并可能发布领域事件。应用层是事务的边界，一个应用服务方法通常在一个事务内完成。这里的关键是“薄”，它不应该有if-else的业务判断，那些属于领域层。

领域层：这是整个系统的核心和灵魂，承载着最本质的业务逻辑和规则。它包含实体（Entity）、值对象（Value Object）、聚合（Aggregate）、领域服务（Domain Service）和领域事件（Domain Event）等核心构建块。这一层应该是“纯净”的，即不依赖任何外部框架、数据库、UI技术等。它的状态变化体现了业务的本质变化。例如，“订单”实体从“待支付”变为“已支付”，这个状态变迁背后是复杂的支付校验、库存预留等规则，这些规则都封装在“订单”聚合内部。保持领域层的独立性，是保证系统核心业务逻辑稳定、可测试的关键。

基础设施层：这是支撑层，为其他各层提供通用的技术能力。它包含数据库访问实现（如MyBatis的Mapper、JPA的Repository实现）、消息队列客户端、文件存储、缓存、邮件发送等具体技术细节。在DDD中，一个重要的原则是“依赖倒置”：领域层定义接口（如OrderRepository），基础设施层提供具体实现（如OrderRepositoryImpl）。这样，领域层就完全与技术细节解耦了。

2.2 依赖方向与解耦关键：守护领域层的纯洁性

经典分层架构的核心是依赖方向永远向下。即上层可以依赖下层，但下层绝不能感知上层。更具体地说：

• 用户界面层依赖应用层。
• 应用层依赖领域层。
• 领域层是独立的，不依赖任何其他层。
• 基础设施层实现领域层（或应用层）定义的接口，因此从代码依赖上看，基础设施层依赖领域层，这体现了“依赖倒置原则”。

这个依赖关系是确保架构清晰、可维护的生命线。在实际项目中，最常见的“坏味道”就是领域层中出现了@Autowired注入了一个具体的技术组件（如RedisTemplate），或者实体类上出现了JPA的@Entity注解。这相当于让核心业务逻辑与特定的数据库技术绑死了。正确的做法是，在领域层定义一个CacheService接口，然后在基础设施层提供一个基于Redis的实现。领域层只通过接口调用，完全不知道背后是Redis还是Memcached。

2.3 适用场景与实操心得：何时选用及如何避坑

适用场景：经典分层架构非常适合作为DDD的入门架构，尤其适用于业务逻辑复杂但相对单体、技术栈统一的系统。它强制建立了清晰的边界，对于团队建立DDD思维模式非常有帮助。

实操心得与避坑指南：

1. 警惕“贫血模型”陷阱：这是最常见的失败模式。领域对象（实体）只剩下getter和setter，所有业务逻辑都放在了应用层或所谓的“Manager”类中。这完全背离了DDD“富血模型”的初衷。要时刻问自己：“这个行为（方法）是不是这个实体在业务上应该具备的？”如果是，就尽量放到实体内部。
2. 应用层不要变成“万能垃圾筐”：避免在应用层堆积大量的业务逻辑。应用层方法应该像剧本一样，清晰地描述“第一步，加载A；第二步，调用A的某个方法；第三步，保存A”。具体的业务规则校验、计算，都应在领域对象内部完成。
3. 基础设施实现的隔离：利用Spring等框架的依赖注入，可以很优雅地实现依赖倒置。将基础设施层的实现类放在独立的包或模块中，并通过@Component扫描或显式配置来注入。确保领域层的编译路径下没有任何具体技术框架的jar包。
4. 测试策略：领域层因为纯净，非常适合做单元测试，测试成本低、速度快。应用层和基础设施层则需要更多的集成测试。清晰的架构让测试策略也变得清晰。

3. 六边形架构（端口与适配器）：以领域为核心的对称之美

如果经典分层架构像一座金字塔，那么六边形架构（Hexagonal Architecture），又称端口与适配器架构（Ports and Adapters），则像一颗六边形的蜂巢，将领域置于绝对中心，所有外部依赖都通过“适配器”对称地接入。

3.1 核心思想：领域是唯一的“内核”

六边形架构的核心思想极其深刻：应用程序的核心业务逻辑（即领域模型）应该是一个独立的、不依赖于任何外部因素的“内核”。这个内核通过定义清晰的“端口”（Port， 即接口）来声明它需要什么功能，或者它对外提供什么功能。而所有与外部的交互，无论是数据库、UI、第三方服务，都是通过“适配器”（Adapter）来实现这些端口。

这个模型彻底打破了传统的“上层-下层”观念。在六边形中，没有上下之分，只有“内部”和“外部”。内部是领域，外部是世界。所有外部访问都必须通过端口，这就像电脑上的USB端口，你不在乎插入的是U盘、鼠标还是键盘，只要它们遵循USB协议（端口），内核就能与之交互。

3.2 端口与适配器详解：驱动侧与被驱动侧

端口分为两大类，这对应了两种不同的交互方向：

• 主适配器（Primary Adapters） / 驱动侧（Driving Side）：这些适配器“驱动”或“调用”应用程序。它们代表外部主动发起的交互。最常见的例子就是Web控制器（Controller）、CLI命令行接口、消息队列的消费者等。它们接收外部输入，将其转换为对内部应用层或领域层的调用。
• 从适配器（Secondary Adapters） / 被驱动侧（Driven Side）：这些适配器被应用程序“驱动”或“调用”。它们代表应用程序为了完成工作所需要依赖的外部服务。例如，数据库仓储实现、调用外部HTTP API的客户端、发送邮件的服务等。它们实现领域层或应用层定义的端口（接口）。

这种对称性带来了巨大的好处：可测试性和可替换性。在测试领域逻辑时，你可以为所有被驱动侧端口创建“模拟适配器”（Mock），内核完全在隔离环境下运行。当需要更换数据库（比如从MySQL换到PostgreSQL）或UI框架（从Spring MVC换到Vert.x）时，你只需要替换对应的适配器，内核代码纹丝不动。

3.3 与分层架构的对比与融合实践

很多人觉得六边形架构和四层架构冲突，其实它们是从不同维度描述问题，完全可以融合。你可以把六边形架构看作是对四层架构中“依赖方向”的强化和可视化。

• 融合方式：在代码组织上，你依然可以保留ui,application,domain,infrastructure这样的包名。但你的认知要改变：ui包里的Controller是主适配器；infrastructure包里的JpaOrderRepositoryImpl是从适配器，它实现了domain包里定义的OrderRepository端口。application和domain共同构成了内核。

• 一个常见的代码结构示例：

src ├── main │ ├── java │ │ └── com │ │ └── example │ │ └── order │ │ ├── application (应用服务， 内核的一部分) │ │ │ ├── OrderApplicationService.java │ │ │ └── dto (命令、查询DTO) │ │ ├── domain (领域层， 核心内核) │ │ │ ├── model (实体、值对象、聚合) │ │ │ ├── service (领域服务接口) │ │ │ ├── event (领域事件) │ │ │ └── port (定义的端口接口) │ │ │ ├── repository (仓储端口， 如 OrderRepository) │ │ │ └── external (外部服务端口， 如 PaymentService) │ │ ├── adapter (适配器层) │ │ │ ├── in (主适配器) │ │ │ │ └── web (Web控制器) │ │ │ └── out (从适配器) │ │ │ ├── persistence (数据库实现) │ │ │ └── client (外部HTTP客户端实现) │ │ └── infrastructure (传统基础设施， 可并入adapter/out) │ └── resources

这种融合实践既保留了分层结构的直观，又贯彻了六边形架构的“内核独立”思想，是我在多个生产项目中采用的模式，效果非常显著。

4. 整洁架构（洋葱架构）：依循依赖规则的同心圆

如果说六边形架构强调对称与端口，那么整洁架构（Clean Architecture， 又称Onion Architecture）则通过一系列同心圆规则，将依赖关系固化到了极致。它由Robert C. Martin（Uncle Bob）提出，是DDD架构思想的另一种经典呈现。

4.1 同心圆分层与依赖规则

整洁架构将软件划分为多个同心圆层，从内到外依次是：

1. 实体层（Entities）：对应DDD中的实体和领域规则，是最稳定、最不易变化的部分。
2. 用例层（Use Cases）：对应DDD中的应用服务，包含具体的业务用例逻辑。它协调实体完成特定操作。
3. 接口适配器层（Interface Adapters）：这一层将内部用例和实体格式，转换为外部系统（如Web、数据库）所需的格式。它包含控制器（Controller）、网关（Gateway）、持久化框架的映射器等。注意，这里定义的仓储接口（Gateway）属于这一层，但其实现不属于。
4. 框架与驱动层（Frameworks & Drivers）：最外层，是具体的工具和框架，如Web框架、数据库ORM、消息队列客户端等。

最核心的规则是：依赖方向只能由外向内。即外层可以依赖内层，内层绝对不能依赖外层。这意味着：

• 领域实体（内层）对Web框架（外层）一无所知。
• 用例层（内层）对数据库（外层）一无所知，它只依赖内层定义的接口。
• 所有外部依赖都必须通过接口进行“反转”，使得核心代码指向接口，而具体实现在外层。

4.2 领域实体与用例的核心地位

在整洁架构中，实体和用例是绝对的核心。实体封装了最高级别的、最通用的业务规则。用例则封装了应用特定的业务规则，它描述了用户与系统交互的完整流程。一个用例对象通常接收一个输入数据（请求模型），调用实体对象的方法，与仓储接口交互，最后产生一个输出数据（响应模型）或副作用。

这种设计带来的一个关键特征是：你可以脱离所有外部框架来测试核心业务逻辑。因为实体和用例不依赖任何外部东西，它们的单元测试可以写得非常快、非常纯粹。这也迫使开发者必须通过接口来定义所有外部交互，从而实现了技术细节与业务逻辑的彻底解耦。

4.3 在复杂业务系统中的落地挑战

整洁架构理念非常优美，但在落地时，尤其是业务极其复杂的系统中，会遇到一些挑战：

1. “用例爆炸”问题：每个用户操作都可能对应一个用例类，在大型系统中，用例层的类数量会非常庞大，管理起来需要良好的目录结构设计。可以按业务能力（Bounded Context）进行模块化划分来缓解。
2. 数据转换的繁琐性：由于每层之间不能传递领域对象（避免外层依赖内层），数据需要在请求模型（Request Model）、领域实体、响应模型（Response Model）、持久化实体（Persistence Entity）之间进行频繁转换。这虽然保证了纯洁性，但也引入了大量的样板代码（Boilerplate Code）。可以使用MapStruct等映射工具来自动化这个过程，但需要团队达成一致的规范。
3. 对团队认知要求高：需要团队成员深刻理解依赖规则，并自觉遵守。任何一次“偷懒”，比如在实体中直接注入一个外层的服务，都会破坏整个架构的纯洁性。这需要严格的设计评审和代码规范。

尽管有挑战，但坚持整洁架构带来的长期收益是巨大的：系统核心极其稳定，技术栈迁移成本极低，测试覆盖率容易提高。它特别适合那些业务生命周期长、技术演进要求高的核心系统。

5. CQRS架构：读写分离的效能革命

当系统的读写负载特征差异巨大，或者读写模型复杂度根本不同时，前面几种架构可能会遇到瓶颈。命令查询职责分离（Command Query Responsibility Segregation， CQRS）架构应运而生，它不是一个完整的、可替代分层或六边形的架构，而是一种可以叠加在其上的、强大的模式。

5.1 核心概念：命令、查询与模型分离

CQRS的核心思想非常简单：将修改数据的操作（命令，Command）和读取数据的操作（查询，Query）完全分离开，甚至使用不同的模型来处理。

• 命令侧：处理创建、更新、删除等操作。它遵循DDD的完整路径：接收命令 -> 验证 -> 通过领域模型执行业务逻辑 -> 持久化 -> 发布事件。命令侧关注的是数据变更的正确性和一致性，模型是“领域模型”。
• 查询侧：处理数据读取操作。它唯一的目标是高效地返回数据，不涉及任何业务逻辑。查询侧可以直接从数据库、缓存或专门优化的读模型中获取数据，模型是“查询模型”（通常是扁平化的DTO，甚至是非规范化的视图）。

这种分离带来了根本性的自由：读写两边可以独立优化。写模型为了业务完整性可以设计得很复杂（聚合、值对象）；读模型为了查询性能可以设计得极其简单（宽表、冗余字段）。

5.2 架构模式剖析：从简单分离到事件溯源

CQRS的实现程度可以有很大差异：

1. 简单CQRS：只是在逻辑上分离了命令和查询的代码路径，共享同一个数据库。例如，应用服务中，CommandService和QueryService是分开的类，但它们可能都操作同一个数据库表。这是入门级实践，能带来代码结构清晰的好处。
2. 独立数据库的CQRS：命令侧和查询侧使用物理上独立的数据库或Schema。命令侧修改“写库”，然后通过某种机制（如数据库触发器、应用层事件、CDC工具）将数据变更同步到“读库”。读库的表结构可以针对查询场景进行完全不同的设计。这极大地提升了查询性能和读写各自的扩展性。
3. CQRS + 事件溯源（Event Sourcing， ES）：这是CQRS的终极形态。命令侧不再保存实体的当前状态，而是保存一系列导致状态变更的领域事件。实体的当前状态是通过按顺序回放所有历史事件计算出来的。查询侧则监听这些事件，并更新自己优化的读模型。ES保证了数据的完整审计轨迹，并能实现强大的“时间旅行”调试功能，但复杂度也最高。

5.3 适用场景与性能权衡：并非银弹

CQRS是一剂猛药，用对了效果惊人，用错了徒增复杂度。

最适合的场景：

• 读写负载极度不均的系统：例如，电商商品详情页的QPS可能是下单操作的数百倍。
• 读写模型复杂度差异巨大的系统：写操作涉及复杂的业务规则和事务，而读操作需要跨多个聚合拼接复杂视图。
• 需要极高查询性能的场景：读模型可以使用Elasticsearch、Redis等专门存储，实现毫秒级响应。
• 需要完整审计日志的场景：结合事件溯源，所有状态变化都有迹可循。

需要警惕的代价与挑战：

1. 最终一致性：一旦读写分离，数据同步就有延迟，查询侧的数据可能不是“最新”的。你必须评估业务是否能接受秒级甚至分钟级的最终一致性。例如，“用户下单后立即在订单列表中看到该订单”通常要求很强的一致性，而“商品销量统计”可以接受延迟。
2. 架构复杂度飙升：你需要维护两套模型、处理数据同步、处理一致性问题。开发、测试、运维的成本都显著增加。
3. 学习曲线陡峭：团队需要理解分布式数据一致性、事件处理等概念。

我的实操建议是：不要一开始就采用CQRS。先从经典分层或六边形架构开始。当你在监控数据中明确看到读写瓶颈，并且业务上确实需要不同的模型来优化时，再考虑引入CQRS。可以先从“逻辑分离”开始，逐步演进到“物理分离”。

6. 微服务架构下的DDD实践：边界上下文与协同

DDD与微服务是天作之合。微服务强调小而自治的服务，而DDD中的限界上下文（Bounded Context， BC）正是定义服务边界的最佳理论工具。一个限界上下文通常对应一个微服务。

6.2 限界上下文的映射与自治

限界上下文是DDD中一个核心的战略设计模式，它明确地界定了一个模型（一套通用语言）的适用范围。在一个上下文内，一个术语有且仅有一种明确的含义。例如，“产品”在“销售上下文”中关注价格、库存、描述；在“物流上下文”中关注重量、体积、包装规格。它们虽然是同一个现实事物的不同侧面，但在软件中应该被建模为两个不同的领域实体，分属两个不同的微服务。

将每个限界上下文实现为一个独立的微服务，带来了天然的自治性：

• 独立开发与部署：团队可以围绕一个上下文工作，使用最适合该领域的技术栈。
• 独立数据存储：每个服务拥有自己的私有数据库，外部服务不能直接访问，只能通过API交互。这避免了数据库层面的紧耦合。
• 弹性与独立扩展：高负载的服务可以独立扩容。

6.2 上下文映射模式：服务间的协作契约

微服务之间必然需要协作，DDD通过上下文映射（Context Mapping）模式来描述这种关系。理解这些模式对于设计稳定的服务接口至关重要。

• 合作关系（Partnership）：两个团队/上下文紧密协作，共同进化。这种模式在微服务中应谨慎使用，容易导致耦合。
• 共享内核（Shared Kernel）：两个上下文共享一小部分公共模型和代码。这能减少重复，但引入了耦合点。共享部分的变化需要双方协调。通常共享一个独立的JAR包或模块。
• 客户方-供应方开发（Customer-Supplier Development）：这是微服务间最健康、最常见的关系。上游（供应方）上下文为下游（客户方）提供明确的API。下游的需求会影响上游的规划，但上游拥有最终决定权。对应微服务中的服务调用。
• 遵奉者（Conformist）：下游上下文完全遵从上游的模型，通常因为上游团队太强大或不愿合作。这简化了下游的设计，但下游失去了自主性。
• 防腐层（Anticorruption Layer， ACL）：这是处理外部或遗留系统依赖的利器。当你的新系统需要与一个设计糟糕或模型不同的老系统交互时，不要直接使用对方的模型。而是在你的边界内建立一个ACL，它负责将外部模型“翻译”成你内部领域能理解的模型。ACL隔离了外部变化对你核心领域的影响。
• 开放主机服务（Open Host Service， OHS）：当一个上下文需要被多个其他上下文访问时，它应该定义一套公开、稳定、文档良好的协议（通常是REST API或消息契约），作为其他上下文与之集成的唯一入口。
• 发布语言（Published Language， PL）：通常与OHS结合使用，指上下游上下文之间用于通信的、公开的、文档化的数据格式（如JSON Schema、Protobuf定义）。这确保了集成的清晰度。

6.3 领域事件在微服务间的集成作用

在单体架构中，领域事件可能只是在内存中发布和消费。在微服务架构下，领域事件成为了服务间进行最终一致性协同的核心机制。

当一个服务内的聚合发生状态变化并发布一个领域事件后，这个事件会被发送到消息中间件（如Kafka， RabbitMQ）。其他对此感兴趣的服务会订阅这些事件，并触发自己内部的业务逻辑。例如，“订单已支付”事件发布后，“库存服务”会消费该事件来扣减库存，“积分服务”会消费该事件来增加用户积分。

这种方式实现了服务间的解耦：订单服务完成支付后，它不需要知道也不关心库存和积分如何处理，它只需要宣告“支付已完成”这个事实。其他服务根据这个事实自行决定做什么。这比同步的RPC调用更具弹性，能更好地应对部分服务故障。

在微服务中实践DDD的要点：

1. 首先用限界上下文划分服务边界，而不是按照技术层或数据表来划分。
2. 为每个上下文建立清晰的通用语言，并在团队内严格执行。
3. 精心设计上下文映射关系，优先使用“客户方-供应方”+“开放主机服务”+“发布语言”模式。对于外部或遗留系统，务必使用“防腐层”。
4. 拥抱最终一致性，利用领域事件作为服务间通信的主旋律之一。
5. 每个服务内部，可以根据其复杂程度，灵活选用经典分层、六边形或整洁架构。

7. 架构选型心法：没有最好，只有最合适

介绍了这么多架构，你可能会问：我到底该选哪一个？我的答案是：从简单开始，随业务演进，混合使用。没有一种架构能通吃所有场景。

7.1 评估维度与决策矩阵

在做技术选型时，可以从以下几个维度评估：

• 业务复杂度：核心领域逻辑是否非常复杂且频繁变化？是的话，需要更强调领域层的纯洁性（六边形、整洁架构）。
• 系统规模与团队结构：是小型单体应用还是大型分布式系统？后者更需要考虑限界上下文和微服务。
• 读写负载特征：是否读远大于写，且读写模型差异大？是的话可以考虑引入CQRS。
• 团队技能与经验：团队对DDD和分布式架构的掌握程度如何？从熟悉的架构开始，降低风险。
• 非功能需求：对性能、一致性、可扩展性、可测试性的具体要求是什么？

一个简单的决策思路：

1. 对于大多数业务系统，以经典分层或六边形架构作为起点是完全合理且稳健的。它能帮你建立起清晰的代码层次。
2. 当系统膨胀为多个团队协作的大型应用时，首先用限界上下文进行模块化拆分（单体模块化），为未来拆分为微服务做准备。
3. 当某个上下文的读写特征出现明显瓶颈，且业务允许最终一致性时，在该上下文内部引入CQRS模式，而不是全盘改造。
4. 整洁架构的理念（依赖规则）应该贯穿始终，无论你采用哪种外层形态，都努力保持领域核心的独立性。

7.2 演进式架构与混合模式

优秀的架构不是一次性设计出来的，而是随着业务认知的深入而逐步演进出来的。我经历过一个项目，最初是一个简单的三层单体。随着业务发展，我们首先引入了清晰的领域层（向经典分层演进）。后来，支付相关的逻辑变得极其复杂且独立，我们将其抽离为一个独立的“支付上下文”模块，并在其内部采用了六边形架构。之后，为了应对海量的交易流水查询，我们在该模块内引入了读写分离的CQRS（共享数据库）。最终，当整个系统需要全面微服务化时，这个“支付上下文”很自然地就成为了一个独立的微服务。

这就是混合模式的威力。你可以在系统的不同部分，根据其具体需求，采用不同的架构模式。全局上可能是一个微服务集群，每个服务内部可能采用六边形架构，而某个特定服务内部又采用了CQRS。关键在于理解每种模式的本质和适用场景，像搭积木一样灵活运用。

7.3 实操中的反模式与警示

最后，分享几个我踩过或见过的“坑”，希望能帮你绕行：

• 过度设计（Over-engineering）：在项目初期，业务还非常模糊时，就引入完整的DDD、CQRS、事件溯源。结果就是被复杂的框架拖累，开发效率极低。记住：简单问题不要用复杂方案。
• 教条主义：死板地照搬书上或文章里的架构图，不允许有任何变通。架构是服务于业务和团队的，而不是相反。如果团队对某个模式理解不深，强行推行只会导致“四不像”的代码。
• 忽略沟通与通用语言：DDD不仅仅是技术，更是沟通。如果团队（包括产品、业务、测试）没有就核心领域术语达成一致，再好的架构也是空中楼阁。定期举行领域知识梳理会，维护一份活的“通用语言”文档，其价值不亚于代码重构。
• 领域层依赖基础设施：这是破坏架构纯洁性的“原罪”。务必利用依赖倒置，让领域接口指向技术实现，而不是反过来。可以通过定期的架构守护（ArchUnit）测试来自动检查。

架构设计的道路没有终点，它是一个持续权衡和演化的过程。最好的架构，就是能让你的团队在面对业务变化时，能够以最小的代价、最高的质量进行响应的那一个。希望这些典型的DDD架构模式和实战心得，能为你下一次的架构设计提供一些切实可行的思路和警示。