领域驱动设计实践

引言

当业务规模发展到一定阶段，传统的“三层架构”和“以数据库为中心”的开发模式会导致业务逻辑碎片化，核心规则散落在各个地方，最终变成无法理清的业务泥潭。领域驱动设计（Domain-Driven Design, DDD）提供了一套将复杂的业务现实转化为清晰代码实现的系统化方法。

战略设计：划定限界上下文

统一语言 (Ubiquitous Language)

在启动设计前，业务专家、架构师和开发人员必须建立统一的词汇表。在特定的业务语境中，同一个名词应该有且仅有一种定义，避免因认知偏差导致的代码缺陷。

限界上下文 (Bounded Context)

限界上下文是统一语言的物理边界。在边界内部，领域的模型定义保持强一致。例如，在电商系统中，“商品”在“库存上下文”中主要体现为“SKU 编码和货位”，而在“营销上下文”中主要体现为“优惠券和促销价”。通过显式划分边界，可以避免建立包含所有属性的巨大“上帝模型”。

战术设计：领域模型落地

实体（Entity）与值对象（Value Object）

• 实体：具有唯一的标识，且在其生命周期中具有延续性。例如，“用户”是一个实体，即使他改了名字，他的 ID 依然保持不变。
• 值对象：没有唯一标识，纯粹由其属性值定义。如果两个值对象的属性完全一致，它们就可以互换。例如，“收货地址”通常是值对象。

聚合与聚合根 (Aggregate Root)

聚合是相关联的领域对象的集合，用以保证业务规则的生命周期一致性。

• 外部对象只能通过聚合根来访问聚合内部的元素。
• 聚合根负责维护其边界内的所有不变式（Invariants，即业务约束）。
• 聚合的设计应遵循“小聚合”原则，防止在并发修改时发生大面积行锁冲突。

经典 DDD 架构模式

干净的六边形架构 (Hexagonal Architecture)

为了保护核心领域逻辑不受到外部框架、数据库以及网络协议的污染，推荐采用六边形架构（端口与适配器模式）。核心领域处于最内层，它不依赖任何外部实现。所有与数据库、第三方 API 交互的代码都作为“适配器”挂载在定义的“端口”上。这种分层模式使得核心业务逻辑极易进行单元测试，并且在更换底层组件时（如从 MySQL 迁移到 MongoDB）可以做到业务代码零改动。