qq_29328443的博客

根据Martin Fowler和Eric Evans的经典定义，Repository模式“作为领域层和数据映射层之间的中介，其行为类似于一个内存中的领域对象集合” 3。它的核心意图是封装被持久化的对象集合以及对这些对象执行的操作，从而为持久化层提供一个更加面向对象的视图 1。持久化抽象 (Abstraction of Persistence)：首要目标是将底层的持久化技术（如SQL、NoSQL数据库或ORM框架）对领域模型隐藏起来。

只有当创建的复杂性——无论是源于内部逻辑的增长，还是外部依赖的引入——真正成为一个问题时，才将它重构为一个独立的、可注入依赖的工厂服务。当系统需要引入新的产品类型时，只需添加一个新的具体产品类和一个对应的具体创建者子类，而无需修改任何现有的客户端代码。我们探讨了它的核心职责、两种主流实现方式，并通过一个详尽的案例展示了其在真实世界中的应用，最后还阐明了它与其他模式的协作关系和设计最佳实践。不变量（Invariant）是DDD中的一个核心概念，它指的是在任何时候都必须为真（保持一致）的业务规则或条件 15。

最出色的设计者，是那些深刻理解规则的人，他们知道何时遵循规则，更重要的是，他们知道何时可以打破规则，并能为自己的每一次“破戒”提供坚实的、源于领域的合理解释 12。这个失败的根源在于，设计者围绕着“伪不变量”（由开发者强加的、而非业务驱动的约束）构建了聚合，导致了不必要的事务冲突。“正确”的设计是在不断的学习和重构中演进而来的。设计的起点是识别出核心的业务规则：“当一个待办事项（BacklogItem）下的所有任务（Task）的剩余工时都为零时，该待办事项的状态自动变更为‘完成’（Done）” 12。

为了进行有意义的讨论，我们必须首先为“纯度”和“完整性”建立严谨且无歧义的定义。这需要我们超越表面的、简单的理解，为后续的深入分析奠定坚实的基础。

划分好限界上下文（我们帝国的各个行省）之后，我们必须明确它们之间是如何协作和通信的。**上下文映射图（Context Map）**就是这样一张描绘上下文之间“外交关系”的地图 20。清晰地定义这些关系，对于避免构建出“分布式单体”——即每个服务都紧密依赖其他服务，无法独立部署和演进——至关重要 9。模式上游上下文下游上下文关系描述具体电商示例客户-供应商 (Customer-Supplier)库存上下文订单上下文。

在 DDD 的所有模式中，限界上下文（Bounded Context）无疑是至关重要且最具变革性的一个。它是一个“语义的上下文边界”，在这个边界之内，通用语言具有唯一、明确的含义，领域模型也受到保护，免受外部概念的侵扰和污染。它就像一个“魔法圈”，圈内的一切都遵循着统一的法则。要理解限界上下文的威力，最好的方式莫过于思考“客户”（Customer）这个词。在一个庞大的企业中，这个词的含义远非统一。

问题描述将一个庞大、复杂的业务领域分解为一组内聚、明确的限界上下文，是一项极具挑战性的任务。团队常常在“如何划线”上挣扎，导致划分出的上下文要么过大（依然是小泥球），要么过小（增加了不必要的集成复杂性），或者内聚性差。深度分析限界上下文是DDD的核心模式，它提供了一个明确的语言和模型边界。在这个边界内，特定的领域模型是统一且无歧义的 5。例如，“订单”这个概念，在“销售”上下文中可能关注价格和客户信息，而在“仓储”上下文中则更关注库存和配送状态 9。

在领域驱动设计的语境中，领域事件被定义为**“在领域中发生、且值得关注的过去之事”** 1。它不是一个执行某项操作的命令（Command），而是一个关于状态变更已经发生这一事实的不可变记录 4。这个概念是 DDD 核心目标的直接体现：创建能够精确反映其所服务的业务领域的软件 1。事件使用**通用语言（Ubiquitous Language）**进行命名，这使得系统的行为变得明确，并且能够被开发人员和领域专家共同理解 3。

聚合（Aggregate）是领域驱动设计中的一个核心模式，它指的是一组被视为单一单元的相关领域对象的集群 1。这个模式的根本目标是管理业务复杂性并确保数据的完整性与一致性 3。聚合最关键的概念是它定义了一个一致性边界在这个边界内部，所有业务规则，即不变性（Invariants），必须在任何事务结束时都得到完全满足 4。例如，一个“订单”聚合可能包含“订单”本身和多个“订单项”。一个核心不变性可能是“订单的总价必须等于所有订单项价格的总和”。

根据领域驱动设计的开创者Eric Evans的定义，聚合是“一组我们为了数据变更而将其视为一个单元的相关对象的集群” 3。关联性和单元性。然而，为了真正理解聚合，我们必须超越这个字面定义。一个简单的对象图（Object Graph）：聚合的设计动机并非为了方便地在对象间导航，而是为了维护一致性 3。一个普通的集合类（Collection Class）：DDD聚合代表的是领域概念（如订单、门诊记录），而集合是通用的数据结构 7。一个数据传输对象（DTO）