最常见领域驱动设计错误
内容提要
本文讨论了领域驱动设计中的常见错误，即错误地将中心概念建模为有界上下文或应用程序接口。强调了将中心概念分解为聚合体，并在不同的有界上下文中封装业务规则的重要性。避免不必要的耦合、团队摩擦和单点故障问题。解释了“限制”、“限定”和“限界”这些词的含义和用法。
延伸解读
中心概念与限界上下文：常见混淆点
文章指出，领域驱动设计中最常见的错误之一是将中心概念（如账户、客户、保单）直接建模为限界上下文或API。中心概念是跨多个业务流程的核心概念，而限界上下文是应用特定规则和流程的业务领域。例如，账户在贷款发放、计费、债务催收等上下文中具有不同的业务规则和表现。混淆二者会导致模型臃肿、不灵活，并违背DDD的核心原则。
错误建模的连锁反应：耦合、摩擦与单点故障
将中心概念视为限界上下文会引发一系列问题。首先，它成为“上帝领域”，导致与其他上下文的紧密耦合。其次，团队围绕该上下文工作，所有变更都需通过它，造成团队摩擦和依赖，降低自主性和发布可预测性。最后，中心概念作为信息源成为单点故障，其故障可能波及无关领域，例如账户创建的内存泄漏可能中断支付调度，影响关键业务功能。
避免陷阱：分解与封装，聚合体是关键
要避免上述错误，关键在于分解和封装。分解是将问题拆解为更小的业务规则块，封装则是定义这些规则的边界，防止泄漏。在DDD中，聚合体是封装单元，负责维护数据完整性，并在限界上下文中通过合适的API定义访问规则。例如，在债务催收上下文中，账户可建模为CollectionAccount聚合，具有特定的行为和模式，与账单上下文中的AccountPayments不同。
术语辨析：限制、限定与限界
文章解释了“bounded”在中文里的不同译法及其细微差别。“限制”强调强制性的约束，如政府设置的旅行限制；“限定”侧重于明确规定范围或条件，如项目时间限定在六个月内；“限界”则指事物的边界或范围，如概念的限界。理解这些术语有助于准确把握限界上下文（Bounded Context）的含义，即在特定边界内应用规则和流程的业务领域。
Q&A
领域驱动设计中常见的错误是什么？
常见错误是将中心概念错误建模为有界上下文或应用程序接口。
如何避免领域驱动设计中的不必要耦合？
通过将中心概念分解为聚合体，并在不同的有界上下文中封装业务规则来避免不必要的耦合。
什么是有界上下文（BC）？
有界上下文是应用某些流程和规则的业务领域，中心概念在不同的有界上下文中有不同的业务规则和表现。
为什么将中心概念视为上帝领域是错误的？
将中心概念视为上帝领域会导致不必要的耦合和团队摩擦，增加依赖性和降低团队的自主性。
如何理解“限制”、“限定”和“限界”的区别？
这三个词在用法和含义上有细微的区别，限制强调强制性约束，限定侧重于特定范围，限界则描述边界或范围。
聚合体在领域驱动设计中的作用是什么？
聚合体是封装单元，负责根据业务流程维护数据的完整性，并定义访问规则。
