DDD架构谈谈你的理解？

# 1. DDD 是什么 以**业务领域**为核心来建模与设计系统的一套方法论与实践。关键是让**模型=代码=语言**一致，避免“需求—设计—实现”层层变形。 * **战略设计（做对的事）**：划分业务疆界 * **Ubiquitous Language 通用语言**：业务和技术共用的词汇表。 * **Bounded Context 限界上下文**：模型的适用边界，每个上下文内部语言一致、模型自洽。 * **Context Map 上下文映射**：上下文之间的协作关系（伙伴、客户/供应商、开放主机、ACL 抗腐层等）。 * **战术设计（把事做对）**：在单个上下文内部的代码结构 * **Entity 实体**（有标识的可变对象）、**Value Object 值对象**（无标识、不可变，表达概念/度量/规则）。 * **Aggregate 聚合** & **Aggregate Root**：事务一致性边界；只允许通过根暴露修改。 * **Domain Service 领域服务**：不自然归属实体/值对象的领域行为。 * **Repository 仓储**：以“聚合”为单位持久化与加载。 * **Factory 工厂**：复杂创建过程。 * **Domain Event 领域事件**：显式表达“发生了什么”。 # 2. 分层与一致性边界 * **Layering**：`Interface/UI` → `Application` → `Domain` → `Infrastructure`。 * **Application** 编排用例、事务边界、授权、发事件；**不写业务规则**。 * **Domain** 只放业务模型与不依赖技术框架的规则。 * **Infrastructure** 实现 Repository、消息、外部适配器。 * **聚合（Aggregate）**是**事务一致性**的最小单元： * 聚合内保持强一致（一个本地事务）。 * 聚合间用**领域事件+最终一致**（Outbox/CDC、重试、幂等）。 # 3. 典型落地做法 * **建模步骤**：事件风暴 → 找名词/动词 → 实体/值对象/聚合 → 划限界上下文 → 画 Context Map。 * **聚合设计要点**： * 依据**不变量**（Invariant）决定哪些对象必须同事务更新；宁小勿大。 * 通过聚合根暴露行为方法，外部不直接改内部成员。 * 读多写少时，用 **CQRS**：命令走聚合，查询走读模型（甚至 ES/缓存）。 * **跨上下文集成**： * **ACL（Anti-Corruption Layer）**：对接遗留系统时做防腐翻译层。 * **领域事件**：`OrderPaid`、`InventoryReserved`；**Outbox** 保证可靠投递；消费者**幂等**。 * 复杂跨聚合流程用 **Saga/Process Manager** 协调，失败补偿而非分布式事务。 * **测试**： * 以**领域用例**写**行为测试**（Given-When-Then），不依赖数据库； * Repository/适配器走集成测试；应用层写端到端用例。 # 4. 何时使用 / 何时别用 * **适用**：业务规则复杂、概念多变、协作上下文多（电商、结算、风控、供应链）。 * **不适用**：纯数据 CRUD、规则简单、生命周期短的小系统（用简单三层/CRUD 快速交付更好）。 # 5. 常见坑 * **把 DDD 当分层/目录结构**：模型没有沉淀到代码里。 * **聚合过大**：一改动就分布式事务/锁竞争。 * **事件乱飞**：没有“谁消费/消费后不变量是什么”的明确契约、缺幂等。 * **通用语言失效**：文档、接口、代码各叫各的。 * **Repository 粒度错**：按表设计仓储，而不是按聚合。 # 6. 一页清单（落地检查） * [ ] 核心域、支撑域、通用域划清？上下文边界定义了吗？ * [ ] 通用语言写成词汇表，评审过？ * [ ] 聚合 = 不变量 + 事务边界，是否“通过根修改”？ * [ ] 跨聚合用领域事件 + Outbox，消费者幂等？ * [ ] 读写分离需要吗（CQRS）？ * [ ] 与遗留系统有 ACL 吗？ * [ ] 行为测试覆盖主要用例？ * [ ] 回滚/补偿策略明确（Saga/补偿动作）？ ## 小例子（电商极简） * **上下文**：订单（Order）、库存（Inventory）、支付（Payment）。 * **聚合**：`Order`（行项目+状态不变量），`InventoryItem`（可用量≥0），`Payment`（授权/扣款状态）。 * **流程**：`OrderPlaced` → 触发 `ReserveInventory`（Saga）→ 成功发起支付 → `OrderPaid`；任何一步失败走补偿事件。 * **一致性**：每个上下文内部本地事务；上下文之间领域事件最终一致。 一句话总结：**DDD 的关键是用“限界上下文 + 聚合（不变量）+ 领域事件”把业务规则固化进模型，让系统的代码结构天然表达业务，而不是被技术细节牵着走。**