领域驱动设计(Domain-Driven Design，DDD) 是一种以业务领域为核心的软件设计方法论，它强调将业务逻辑与代码实现紧密结合，通过统一的领域模型来驱动整个软件的设计与开发。

DDD的核心组件与实践

我们可以把 DDD 的核心组件分为几个层次来理解：

1、战略设计

这是宏观层面的设计，关注如何划分和组织整个系统。

领域(Domain)：指一个组织所做的事情以及其中所包含的一切。

子领域(Subdomain)：一个复杂的领域可以被划分为更小的、边界清晰的子领域。

核心子领域(Core Domain)：业务的核心竞争力所在，是创造主要价值的地方。

支撑子领域(Supporting Subdomain)：为核心子领域提供支持，本身不具备核心竞争力。

通用子领域(Generic Subdomain)：可以被多个子领域复用的功能，如用户认证、日志等。

限界上下文(Bounded Context)：这是 DDD中最关键的概念之一。 它定义了一个边界，在这个边界内，领域模型中的所有术语、规则和对象都具有明确且一致的含义。

可以把它理解为一个“业务微服务”或一个“模块”的边界。不同限界上下文之间通过明确的接口(上下文映射)进行通信。

2、战术设计(Tactical Design)

这是微观层面的设计，关注在单个限界上下文内如何构建领域模型。

实体(Entity)：具有唯一标识的对象，其核心是“身份”，而不是属性。即使属性发生变化，身份依然不变。

值对象(Value Object)：用于描述事物的状态或属性，没有唯一标识。它的equality 基于其属性值。

聚合(Aggregate)与聚合根(Aggregate Root)：聚合：是一个或多个实体和值对象的集合，它们被视为一个整体，有统一的业务规则和生命周期。

聚合根：是聚合的入口点和管理者，是聚合中唯一能被外部直接访问的实体。它负责维护聚合内部的一致性。

领域服务(Domain Service)：当一个业务操作不属于任何一个实体或值对象时，就应该将其封装为领域服务。它通常协调多个实体来完成一个复杂的业务任务。

例如：支付服务(PaymentService)可能需要协调订单(Order)、用户账户(UserAccount)和支付网关(PaymentGateway)来完成支付流程。

领域事件(Domain Event)：用于记录领域中发生的重要事情。它可以被其他部分订阅，以实现领域内的解耦和异步通信。