限界上下文与集成

• 限界上下文的定义
• 业务能力与组织边界的对齐
• 康威定律的影响

限界上下文（Bounded Context）是 DDD 中模型与语言的边界，边界内每个术语有唯一、明确的含义，边界外模型独立演化。战略设计时，上下文边界应主要依据"业务能力"（business capability）划分：一个上下文对应一组内聚的业务能力，有独立的模型、语言、持久化与团队。同时要考虑组织边界（康威定律：系统结构趋同于沟通结构），上下文边界最好与团队边界对齐，让负责该能力的团队拥有并演化该上下文，减少跨团队沟通成本。业务能力是"做什么"，组织边界是"谁来做"，两者对齐时上下文边界最稳定。

限界上下文是"模型、语言、持久化、团队"的边界。只按业务能力而不考虑组织，跨团队协作会互相踩模型；只按组织而不考虑业务能力，会造成上下文内聚度差。战略设计的核心是让业务能力与组织边界对齐，形成清晰、自治、可演化的上下文。

• 四种上下文关系的含义
• 各自的适用场景
• 协作方式与依赖方向

Context Map 描述限界上下文之间的协作关系。四种典型关系：Partnership（伙伴关系）——两个团队协同开发、共同演进，依赖强、需频繁同步；Shared Kernel（共享内核）——多方共享一小部分共同模型/代码，需严格同步与变更控制；Customer-Supplier（客户-供应商）——上游（supplier）提供模型，下游（customer）依赖上游，上游有优先权但需对下游负责（如契约测试）；Anti-Corruption Layer（防腐层）——下游为保护自己的模型，在边界建立翻译层，转换上游模型，阻断上游"污染"下游模型。四种关系代表不同协作强度与依赖方向，映射到团队协作模式与集成方式。

四种关系是"上下文如何协作"的模板。选择取决于协作强度与依赖方向：关系紧密且能同步选 Partnership/Shared Kernel；依赖明确分上下游选 Customer-Supplier；强隔离、模型差异大选 ACL。Context Map 帮助团队明确协作规则与边界责任。

• Conformist 关系的定义
• 上游主导、下游跟随
• 采用 Conformist 的代价与边界

Conformist（顺从者）关系是指下游团队放弃设定自己的模型，直接采用上游团队提供的模型，以消除翻译成本。适用场景：上游模型足够好、下游没有施加影响的意愿与能力、双方模型差异可接受、翻译成本高于顺从成本。其边界在于：下游自愿、明确地接受上游模型，契约由上游主导，下游跟随上游变更；若上游模型不适合下游业务或下游需要独立演化，则不应采用 Conformist，而应改用 ACL 保护下游模型。Conformist 的代价是下游模型被上游牵着走，失去自主性。

Conformist 是"省翻译成本"的取舍，前提是上游模型可信、下游影响动机弱。它是 Customer-Supplier 的强依赖极端。边界判断：若下游只读上游、无独立建模诉求，顺从者省事；若下游有独立业务语言，就必须用 ACL 隔离。

• Translator 与 Facade 的分工
• 失败模式设计（超时、降级、缓存）
• 避免透传层

防腐层（ACL）由两个概念组成：Facade（外观）提供下游模型的统一入口，屏蔽上游接口细节；Translator（翻译器）负责把上游模型翻译成下游模型（双向），承担数据转换与语义映射。ACL 内部需处理失败模式：对上游调用设置超时、熔断，失败时降级（返回默认值/缓存副本/失败重试），对高频数据做缓存，避免上游故障拖垮下游。避免 ACL 退化为"透传层"的关键：ACL 必须做真正的模型翻译与语义转换，而不是把上游 DTO 原样透传；ACL 内应有业务适用的下游模型、转换逻辑与失败处理策略，而不是仅停留在"协议翻译"与"语义透传"。

ACL 的价值在于"隔离与转换"：它把上游模型挡在下游之外，下游只识自己的模型。若只透传 DTO，则上游模型污染下游，ACL 形同虚设。Translator 承担语义转换、Facade 承担入口与容错，配合超时/降级/缓存，ACL 才真正成为可靠防线。

• 康威定律对上下文划分的影响
• 上下文与团队一对一映射
• Shared Kernel 的协作机制

康威定律指出"系统结构趋同于沟通结构"，因此限界上下文边界应尽量与团队边界对齐：一个上下文由一个团队拥有、独立演进，团队之间通过明确定义的接口/契约协作，实现"团队自治、上下文自治"。若上下文边界与团队边界错位，跨团队频繁改同一模型会造成严重协调成本。Shared Kernel 是多方共享一小部分模型/代码，需严格协作机制：明确共享范围且尽可能小、共享变更需多方评审、同步频繁、共享代码有清晰版本与测试、变更需要通知所有共享方。若共享成本过高，应考虑改用其他关系（如 ACL）。

上下文与团队对齐是"自治团队 + 自治上下文"的落地，减少跨团队协调。Shared Kernel 是例外：它共享模型，必须靠机制（评审、同步、测试、通知）控制变更，否则共享范围失控会退化为"全世界共享一个模型"。

• Open Host Service 的定义
• 契约稳定性的责任
• 对下游的承诺

Open Host Service（开放主机服务，OHS）是一个上下文对外暴露的、以明确协议（API/消息/接口）形式提供服务的边界，它把内部模型转换为对外契约，是下游消费的稳定入口。其"契约稳定性责任"在于：上游负责维护契约的稳定与向后兼容，确保对下游的破坏性变更最小化；契约一旦发布应视为承诺，变更需遵循版本化、兼容性规则，避免直接破坏下游。OHS 常与 Published Language（发布语言）配合，用标准化数据格式表达契约。契约稳定性通过消费者驱动契约测试（如 Pact）守护。

OHS 的责任核心是"契约即承诺"：上游不能随意变更对外契约，否则破坏所有下游。稳定性靠版本化、兼容性检查、契约测试与变更管理保障。OHS 是对下游友好、自洽的开放边界。

• Published Language 的定义
• 标准化数据格式
• 与 OHS 的配合

Published Language（发布语言）是上下文之间共享的、被明确文档化的标准化数据格式/协议，用于跨上下文通信，使各上下文无需理解对方内部模型即可交换数据。它通常与 Open Host Service 配合：OHS 定义服务/协议，Published Language 定义传输的数据格式（如 JSON Schema、XSD、消息 DTO）。设计要点：格式独立、自描述、版本化、向后兼容；用公开的 schema 表达，避免暴露内部模型；字段命名与语义清晰，避免上下文特色的术语歧义。它对所有参与者公开，作为跨上下文的"共同语言"。

Published Language 是跨上下文解耦的基础：各上下文只依赖发布的语言，不依赖对方内部模型。它把"事实/数据"标准化，配合契约测试保证格式稳定，是跨团队协作与消息集成的标准做法。

• Shared Kernel 的共享范围
• 变更同步机制
• 协同责任

Shared Kernel（共享内核）是多个上下文共享的一小部分模型/代码，其协同责任包括：共享范围必须尽可能小且明确（只共享真正需要一致的、稳定的部分）；共享代码的变更需要多方评审与同步，不能单方随意改动；变更需频繁同步并保证所有共享方一致；共享代码要有完善的测试与版本控制。变更同步机制：共享变更走共同评审流程、持续集成同步构建、变更通知所有共享方、必要时用并发版本管理。若共享范围过大或同步成本过高，应评估是否改为独立模型 + ACL/翻译。

Shared Kernel 是"共享模型"的务实选择，但它有强耦合风险。核心是控制共享范围并建立"变更共同负责"的机制，否则共享内核会退化为紧耦合的全局模型。频繁同步 + 共同评审是维持其健康的关键。

• Big Ball of Mud 反模式
• 渐进式划分
• 从泥球到上下文的演进

Big Ball of Mud（泥球）是指没有清晰边界、架构混乱、任意代码相互依赖、全局共享模型与数据库的系统，是 DDD 要避免的反模式。治理方向是渐进划分（strangler/scavenging）：不一次性重构，而是逐步识别并界定限界上下文。步骤包括：识别内聚的业务能力与自然边界，从现有代码中"挖出"候选上下文；为每个上下文定义独立模型、语言与持久化边界；用防腐层（ACL）隔离新上下文与遗留泥球；通过上下文映射明确新边界关系；逐步迁移数据与代码，让泥球被一个个上下文"殖民"。渐进划分控制风险，边运行边重构。

泥球没有边界，无法演进。渐进划分通过"先划边界、再隔离、再迁移"逐步把混乱系统拆成有界上下文，避免一次性大规模重构的高风险。每次划分都带来可验证的改善，是治理遗留系统的务实路径。

• Core Domain 的定义
• 识别方法
• 战略投资的原因

Core Domain（核心域）是系统中最能给业务带来差异化竞争优势、最值得投入的领域，是公司竞争力的核心来源。识别方法：分析哪些业务流程/能力直接决定业务价值与差异化、哪些最复杂且最需要精细建模、哪些一旦出错代价最大。Core Domain 应投入最强的人才（资深领域专家、资深工程师）、最多的协作（与业务方紧密协作、深入建模）、最精良的架构（优先引入所需模式与工具）。因为核心域是竞争护城河，投入产出比最高；而通用域（Generic）与支撑域（Supporting）可用成熟方案/外包，把稀缺资源聚焦核心域。

战略投资的核心是"把资源集中在高价值、高差异化的核心域"。识别核心域让团队清楚"哪里值得精益求精"，避免在无关紧要的通用域过度投入。核心域的战略地位决定了人才、时间与架构的倾斜。

• 子域与上下文的关系
• 团队与语言的对应
• 划分的准则

限界上下文的划分综合三个维度：子域（Subdomain）——依据业务能力与领域知识划分，一个上下文通常对应一个或多个内聚子域；团队——上下文边界与团队边界对齐，保证一个团队拥有一个上下文的全部演化权；语言（Ubiquitous Language）——每个上下文有自己唯一的统一语言，术语在此上下文内含义唯一，跨上下文共享是"发布语言"而非内部语言。划分准则：上下文应内聚、自治、可独立演化，边界内模型与语言一致，持久化独立，团队可独立交付。子域决定"边界在哪"，团队决定"谁拥有"，语言决定"边界内如何表达"。

三者共同界定上下文：子域是业务基础，团队是组织容器，语言是边界表达。上下文边界清晰时，子域、团队、语言三者一致，形成自治单元。若三者错位，会产生跨团队耦合与术语冲突。

• 消费者驱动契约的原理
• 契约测试的编写
• 版本管理与 CI 集成

消费者驱动契约（Consumer-Driven Contracts，CDC）由消费者（下游）定义契约（期望的请求/响应），生产者（上游）验证满足契约，从而让 OHS 契约以"消费者需求"为准，保证稳定与兼容。Pact 与 Spring Cloud Contract 是两类工具。编写：消费者用 Pact 生成契约（期望 URI、请求、响应），生产者用 Spring Cloud Contract 定义契约 DSL（given/when/then）并生成测试。版本管理：契约文件版本化，与 API 版本对应；生产者在 CI 中验证契约，发布前跑契约测试确保向后兼容。CI 集成：消费者 CI 生成契约发布到契约仓库（Pact Broker），生产者 CI 拉取契约并验证，任一不兼容即失败，实现"契约勿破坏"的自动守护。

消费者驱动约束使 OHS 契约稳定：契约由消费者定义、生产者验证，任何破坏性变更在 CI 即被发现，避免线上破坏下游。契约仓库（Pact Broker）+ CI 验证形成"契约一致性"的自动化守护，是消费者驱动契约的核心价值。

• 同名异义与同义异名
• 术语冲突的识别
• 翻译映射表的管理

跨上下文术语冲突表现为两类：同名异义（同一术语在不同上下文含义不同，如"订单"在交易与物流上下文含义不同）与同义异名（同一概念在不同上下文有不同术语，如"客户 Customer"与"账户 Account"）。识别方法：梳理各上下文统一语言，对比术语的含义与所指，标记冲突；通过事件风暴/领域建模让各团队澄清术语定义。维护翻译映射表：建立上下文间的术语映射表，记录各上下文术语的对应关系与含义差异，作为集成与翻译（ACL/Translator）的依据；映射表随上下文演进持续更新，并用于生成集成契约。翻译映射表避免了"想当然共用术语"导致的语义错误。

术语冲突是跨上下文集成错误的高发源。识别靠"统一语言 + 语义对比"，治理靠"翻译映射表"显式记录差异，让集成层（ACL）据此做正确翻译，而不是盲目复制字段。映射表是上下文协作的"词典"。

• 三种子域类型的定义
• 各自的差异化程度
• 投资策略

Subdomain（子域）是业务领域的划分，分三类型：Core Domain（核心域）——业务差异化与竞争优势的核心，最复杂、最值得投入，需深度定制与精细建模；Supporting Subdomain（支撑域）——支撑核心域但非差异化，需定制但可简化，如内部授权管理；Generic Subdomain（通用域）——通用、无差异化、市场已有成熟方案，如认证、通知、支付，可购买或外包、用成熟产品。三类子域的投资策略：核心域投入最强资源，支撑域适度投入，通用域尽量用现成方案，把稀缺资源集中到核心域。

子域分类是"战略投资"的基础：不同类型子域差异化程度不同，决定投入策略。核心域定制、支撑域定制但简化、通用域买现成，避免在通用域浪费研发资源，突出核心域竞争力。

• 三种集成方式
• RPC（同步）与消息（异步）的场景
• 共享数据库的缺点

上下文间集成方式有：RPC（同步调用，如 REST/gRPC）、消息（异步事件/命令，如 Kafka/RabbitMQ）、共享数据库（直接共用数据库）。RPC 适合强一致、实时性要求高、需要立即响应的场景，但有同步耦合与可用性依赖；消息适合解耦、异步、最终一致、事件驱动场景，扩展性强、抗故障；共享数据库是反模式——上下文直接访问同一数据库会导致模型耦合、无法独立演化、事务边界混乱，应避免，改为通过 API/消息集成。选择时根据一致性需求、耦合度与可用性权衡。

集成方式的选择影响上下文自治性。共享数据库破坏上下文边界，应避免；RPC 保实时但耦合；消息保解耦但最终一致。粒度上，跨上下文尽量用消息或受控 RPC，保持各自持久化独立。

• 上下文间一致性
• 最终一致的原因
• 异步协调

限界上下文之间通常不共享数据库、不共享事务，因此无法保证强一致，而是通过事件/消息实现最终一致（Eventual Consistency）：一个上下文变更后发布领域/集成事件，其他上下文异步订阅并更新自己的状态，通过补偿、重试、幂等处理最终达到一致。原因是跨上下文强一致需要分布式事务（2PC），复杂、脆弱、性能差，且上下文自治要求独立事务边界。最终一致虽有时延，但换取了解耦、可扩展与自治。关键是用事件 ID 幂等、重试与补偿保证收敛。

上下文自治意味着不共享事务，一致性只能靠异步最终一致。最终一致是"解耦与自治"的代价，通过幂等消费、重试、补偿机制保证最终收敛。SLA 需明确定义传播延迟。

• 模块化单体的概念
• 模块与上下文对应
• 边界强制的收益

模块化单体（Modular Monolith）是单进程部署但内部按模块清晰划分的系统，模块之间通过明确接口隔离、禁止跨模块直接访问内部，与限界上下文结合：每个限界上下文对应一个模块，模块拥有自己的模型、仓储与持久化，模块间通过接口或事件通信，依赖方向受控（可用架构测试强制）。这样既保留了单体部署的简单性（无分布式事务、易运维），又获得上下文界清晰的架构收益（模块自治、可独立演进、未来可拆分为微服务）。模块化单体是"上下文 + 单体"的务实结合，是微服务前的过渡形态。

模块化单体把"上下文边界"内化到单体内部，用模块与架构测试强制边界，避免泥球。它保留单体运维简单，同时具备清晰边界，是避免过早微服务化的好选择。当某模块需独立扩展时再拆为独立服务。

• Context Map 的文档内容
• 记录方式
• 文档的作用

Context Map 文档用图形与文字记录限界上下文之间的所有关系，包括：每个上下文的名称、边界、统一语言、所属团队；上下文之间的协作关系类型（Partnership、Shared Kernel、Customer-Supplier、ACL、Conformist、OHS 等）；集成方式（RPC、消息、共享数据库）；不一致的术语与翻译映射。记录方式可以是 UML 类图/上下文映射图、表格、Markdown 文档，或用专门的 DDD 建模工具。文档应随上下文演进持续更新，作为团队协作与架构评审的依据。

Context Map 是"上下文间关系的路线图"，帮助团队理解边界、协作与依赖。它是活的文档，需与代码、契约保持一致，避免"文档与实现脱节"。清晰记录关系让团队知道"谁依赖谁、如何协作、如何保护自己"。

• 上下文过大/过小的识别
• 拆分与合并的信号
• 演进驱动因素

限界上下文过大的信号：模型复杂、术语过多且含义不一、团队协作频繁冲突、模块臃肿、边界内内聚度差、依赖关系复杂。驱动因素：团队规模增大、系统复杂度上升、性能与扩展需求。此时应拆分上下文，按内聚业务能力与团队边界划分。过小上下文的信号：上下文过多、团队协作成本高、上下文间调用频繁、共享数据与模型、边界过度碎片化、分布式事务泛滥。驱动因素：过度拆分导致集成复杂。此时应合并上下文，把内聚、频繁协作的上下文合并为一个。演进核心是"让上下文与内聚业务能力及团队边界重新对齐"，保持自治与可维护。

上下文边界不是固定不变的，随团队与系统演化调整。过大则拆分（内聚度下降、协作冲突），过小则合并（集成成本过高、碎片化）。演进以"内聚、自治、团队对齐"为准则，动态平衡。