架构设计

领域驱动设计(DDD) 领域驱动设计（Domain-Driven Design, DDD）是一种以领域模型为核心的软件开发方法论，旨在应对复杂业务系统的设计与演进。DDD 分为战略设计和战术设计两个层面：战略设计关注系统整体的边界划分与团队协作模式，战术设计则聚焦于领域模型的具体实现模式。 1. 战略设计 战略设计的目标是从整体上划分系统的限界上下文（Bounded Context），并在每个上下文中发展出清晰一致的通用语言（Ubiquitous Language）。 1.1 领域与子域 领域（Domain）：系统所关注的问题范围，代表业务活动和规则的集合。 子域（Subdomain）：领域的组成部分，将复杂业务划分为更小、更聚焦的单元。 子域通常分为三类： 类型 说明 核心域（Core Domain） 业务的核心竞争力所在，需要重点投入 支撑域（Supporting Subdomain） 支撑核心业务运作，但非核心竞争力 通用域（Generic Subdomain） 通用功能，可采用现成方案 领域分析发生在问题空间（Problem Space），而领域模型的设计与实现属于解决方案空间（Solution Space）： 问题空间：识别业务目标和边界，关注"做什么"。 解决方案空间：将需求转化为可实现的设计和模型，关注"怎么做"。 1.2 限界上下文（Bounded Context） 限界上下文是领域模型的语义边界。在该边界内，所有的概念、对象和规则都有明确且一致的含义。 同一个术语在不同上下文中可能代表不同含义，而在同一上下文中则保持语义一致。 例如，“账户"在用户上下文中可能指用户登录凭证，而在财务上下文中则指资金账户。限界上下文的划分有助于避免模型的混淆和污染。 1.3 通用语言（Ubiquitous Language） 通用语言是限界上下文内部领域专家与开发人员共享的统一语言。它通过领域模型来表达业务规则、行为和约束。 每个限界上下文都有自己独立的通用语言 通用语言不能跨上下文混用 代码、文档、沟通都应使用通用语言 1.4 上下文映射（Context Mapping） 当不同的限界上下文需要交互时，必须通过上下文映射来完成语言的"翻译"和语义对齐。上下文映射定义了上下文之间的关系、通信模式以及模型转换方式。 常见的上下文映射模式包括： 模式 说明 合作关系（Partnership） 两个团队共同协调开发，相互依赖 共享内核（Shared Kernel） 共享部分模型代码，需谨慎管理 客户-供应商（Customer-Supplier） 上游供应、下游消费，下游可提需求 遵奉者（Conformist） 下游完全遵从上游模型 防腐层（ACL） 下游建立转换层隔离上游模型 开放主机服务（OHS） 上游提供标准化协议供多方使用 发布语言（Published Language） 使用标准化的数据交换格式 1.5 防腐层（Anti-Corruption Layer） 下游上下文在使用上游上下文的数据或服务时，应建立一个防腐层（ACL）。防腐层负责： ...