Hey!
Billgo

EN

理解整洁架构与领域驱动设计

2023 年 10 月 1 日

在软件开发领域，有两种被广泛采用的方法常被用来构建稳健且可维护的应用：整洁架构与领域驱动设计（DDD）。本文会介绍这两个概念，并通过实际例子说明它们的使用方式，同时讨论各自的收益与注意事项。读完之后，你会更清楚在哪些场景下可以有效使用这些方法。

整洁架构及其实际应用

整洁架构

整洁架构是一种非常强调软件系统组织方式和结构边界的架构模式。它的主要目标包括可维护性、灵活性和可测试性。这个模式主张关注点分离，并强调业务代码应尽量独立于外部框架和技术。

整洁架构通常由多个清晰的层组成，包括实体、用例、接口，以及框架/驱动层。每一层都有明确的职责和依赖关系。它遵循依赖规则：依赖方向应始终指向内部。这样可以获得更高的模块化能力，也更容易替换或修改外部组件。

下面通过两个实际例子看看整洁架构如何落地：

  1. 用户注册系统：在 Web 应用的用户注册系统中，核心业务实体是 User。RegisterUser 用例负责管理注册流程，包括校验输入数据，并通过 UserRepository 接口完成数据持久化。外部框架或驱动层则包含处理 HTTP 请求的 Web 框架，以及用于保存用户数据的数据库驱动。
  2. 电商结账流程：在一个包含复杂结账流程的电商应用中，Cart 实体表示购物车，PlaceOrder 用例负责下单，执行库存校验、订单总价计算等业务规则。该用例通过 OrderRepository 接口进行持久化。框架或驱动层则包括 Web 界面、支付网关集成和数据库存储等组件。

领域驱动设计及其实际应用

领域驱动设计

领域驱动设计（DDD）关注如何有效建模核心业务领域，并让软件设计与该领域中的概念和流程保持一致。它强调领域专家与开发者之间的紧密协作，从而建立共同语言和共同理解。

DDD 引入了限界上下文的概念。限界上下文把一个大型软件系统拆分为多个更小、更易管理的上下文。每个上下文都有自己的模型、规则和通用语言。这让不同团队可以相对独立地负责系统中的不同部分。

下面看两个 DDD 的应用例子：

  1. 银行系统：银行系统可以通过定义“账户管理”和“交易处理”等限界上下文来受益于 DDD。每个上下文都有自己的领域模型、规则和通用语言。“账户管理”上下文可能包含 Account、Customer 等实体，而“交易处理”上下文可能包含 Transaction、Transfer 等实体。这种拆分可以让不同团队独立协作，并确保每个上下文内部的理解保持清晰。
  2. 在线预订系统：对于酒店在线预订系统，可以识别 Hotel、Room、Reservation 等关键领域实体。AvailabilityService 这样的领域服务可用于检查房间可用性并执行预订规则。同时，BookingConfirmed 这样的领域事件可以用于传递变化，并在系统内部触发后续动作。

整洁架构的优点与缺点

整洁架构有几个明显优点：

  1. 可维护性：清晰的关注点分离和独立分层，使维护和更新更容易，不会轻易影响整个系统。
  2. 灵活性：架构与框架、技术解耦，更容易引入新工具或替换技术栈。
  3. 可测试性：依赖边界清晰，组件可以在测试中被隔离，从而获得更完整、更可靠的单元测试。

不过，整洁架构也有一些需要考虑的缺点：

  1. 复杂度增加：分层结构和严格依赖规则可能带来额外复杂度，尤其是在需求简单的小型项目中。
  2. 初始成本较高：实现整洁架构需要前期规划、架构设计和接口定义，可能需要投入更多时间与精力。

领域驱动设计的优点与缺点

领域驱动设计也有几个重要优势：

  1. 与领域专家协作：DDD 鼓励开发者与领域专家主动协作，确保团队深入理解业务领域，并更准确地进行建模。
  2. 可扩展性与适应性：DDD 的限界上下文和模块化方式让团队可以独立工作，也更容易适应不断变化的需求。
  3. 演进式设计：DDD 支持迭代式、增量式设计过程，让领域模型可以随着业务变化而持续演进。

同时，也需要注意以下事项：

  1. 学习曲线：DDD 需要理解新的概念和模式，对于不熟悉这种方法的开发者来说，前期会有一定学习成本。
  2. 复杂度管理：合理定义和管理限界上下文，并确保它们之间良好集成，在大型复杂系统中会比较有挑战。

共同点与差异

整洁架构和 DDD 是不同的概念，但它们也有一些共同点：

  1. 关注点分离：两者都强调通过关注点分离来获得可维护、模块化的代码库。
  2. 可测试性：两者都通过隔离依赖、在不同层级进行单元测试来提升可测试性。

两者的区别在于：整洁架构主要关注软件系统的整体结构，而 DDD 关注核心业务领域的建模。整洁架构处理的是架构分层和依赖管理；DDD 提供的是领域建模、模式设计以及与领域专家协作的原则。

如何选择合适的方法：整洁架构和 DDD 的选择取决于项目的具体需求与上下文。如果项目特别重视架构层面的关注点，比如关注点分离和可测试性，那么整洁架构很适合。相反，如果领域复杂度较高，且需要领域专家深度参与软件设计，那么 DDD 更合适。

总之，整洁架构和领域驱动设计都为开发可维护、设计良好的软件系统提供了有价值的方法。理解它们的概念、实际应用场景，以及各自的优缺点之后，你就可以更理性地判断何时以及如何在自己的项目中使用这些方法。

记得根据自己的具体需求调整和细化这些概念，并始终优先考虑最终目标：交付高质量、并且与业务领域保持一致的软件。