这一课属于 DDD 的“战略层设计Strategic Design”部分也是本课程的收束与未来演进指南。本课会带你从单体 → 模块化 → 上下文拆分 → 微服务 → 企业级架构并包含Anti-Corruption LayerACLContext Map上下文关系企业真实项目中 DDD 的落地方式架构演进路线非常关键第8课回顾与演进本课学习目标复盘前 1–7 课学到的 DDD 能力学会如何从单体走向微服务掌握上下文地图Context Map理解 Anti-Corruption Layer 的必要性能够制定系统的未来演进路线理解 DDD 在真实企业中的落地方式与限制复盘前 7 课的完整知识体系按照 DDD 战术建模Tactical Design和战略建模Strategic Design的分类我们整理出本课程的全景图✔ 战略Strategic DDD统一语言Ubiquitous Language限界上下文Bounded Context上下文地图Context Map团队边界与系统边界一致化✔ 战术Tactical DDDEntity / Value ObjectAggregate / Aggregate RootRepositoryApplication Service / Domain ServiceDomain EventCQRS至此你已经掌握了 DDD 两大部分的核心内容。二、上下文地图Context Map——系统之间的关系在第 1 课我们识别了订餐系统的多个上下文现在我们正式绘制 Context Map。订餐系统的上下文图示例---------------------- ---------------------- | Menu BC |◀───▶ | Inventory BC | | (菜单价格类目) | | (库存、扣减、补货) | ---------------------- ---------------------- ▲ USES │ ▼ ---------------------- ---------------------- | Order BC |────▶ | Payment BC | | (订单、状态、结算) | | (支付、退款、对账) | ---------------------- ---------------------- │ PUBLISHES EVENTS ▼ ---------------------- | Delivery BC | | (配送、骑手调度) | ----------------------关键的上下文关系DDD 提供 8 种上下文关系模式我们选择与项目最贴合的Customer-Supplier客户–供应者Order BC依赖Menu BC提供商品信息Order BC依赖Inventory BC库存校验Order BC依赖Payment BC支付结果Conformist从属者Order BC 在调第三方支付如支付宝/微信时不可能让外部系统为了你改变接口因此只能适配对方这就是 Conformist。Published Language共享语言Order BC 发布领域事件其他上下文如 Delivery BC订阅它。这就形成了清晰的架构结构。三、Anti-Corruption LayerACL——防止外部系统污染你的领域当一个 BC 必须调用外部系统时例如 Order BC 调用 Payment 平台我们必须避免外部模型污染领域模型外部字段名强耦合到内部代码引入“贫血模型”或“交易模型”到领域层让外部系统的变化导致内部崩溃因此我们引入Anti-Corruption Layer隔离外部系统的翻译层ACL 的结构当 Order BC 需要调支付系统时[Order Domain] → [ACL Adapter] → [Payment API] ↑ 负责模型转换ACL 包含Facade对内暴露简化接口Adapter对外接口调用Translator模型转换Anti-corruption mappings外部数据映射示例伪代码外部支付返回{trade_no:...,status_code:200,msg:OK}你不能直接把它塞进领域模型。必须通过 ACL 翻译classPaymentResultTranslator{publicPaymentResulttranslate(ExternalPayResponseres){returnnewPaymentResult(res.trade_no,statusFromCode(res.status_code));}}Order BC 永远不接触外部字段名、结构、协议。四、系统演进路径企业级系统不会一步走到微服务。典型路线如下阶段 1单体 DDD 分层interfaces application domain ← 你的核心资产 infrastructure特点单体领域模型稳定架构清晰非常适合作为后续拆服务的基础阶段 2组件化 / 模块化DDD Module将单体拆成多个模块order-module menu-module inventory-module payment-module以 Maven module 或 Gradle sub-project 的形式存在。阶段 3上下文边界固化逐步拆分微服务当某个模块满足有独立数据库需求有大量独立流量有独立 SLA需要独立扩展才拆出去比如order-service payment-service delivery-service拆分后需要事件驱动最终一致性分布式事务SagaACL 适配层阶段 4企业级事件驱动体系EDA特点Kafka / Pulsar 作为事件总线所有上下文通过事件通信读库事件驱动更新CQRS可扩展至千万级订单阶段 5领域平台化 / 领域组Domain TeamsDDD 的最终目标是开发团队的结构反映系统的结构。团队边界 业务边界 Bounded Context。即 Conway’s Law 反向应用。五、真实企业使用 DDD 的注意事项DDD 不适合小项目CRUD 足够只做增删改查的系统团队规模过小需求变化巨大但业务不复杂DDD 适合业务规则多状态复杂高并发多团队协作系统可持续迭代多年第8课总结你已经掌握战略设计上下文、ACL、地图战术设计实体、聚合、事件、CQRS企业级系统演进路径如何让系统可持续演进而不是重写你已经拥有了可用于高质量架构设计、组织设计、系统拆分的能力。