Bounded Context和域边界

Bounded Context（BC）是单个Ubiquitous语言，一致模型和不变量在其中运行的清晰边界。在边界内，术语是明确的（"Stake"，"Customer"，"Limit"），向外上下文通过合同（事件/命令）进行交流，并且不会向内拉其他语义"尾巴"。精心选择的边界减少了连通性，简化了缩放并加快了产品的进化。

1）为什么需要边界

认知负荷降低。该团队使用一种模型和一种语言，而不是"同时进行整个业务"。
不变量隔离。关键规则（平衡≥ 0，登录的唯一性）生活在同一位置，并受到集合的保护。
变更管理。卑诗省内部计划/规则的演变不会打破邻居-有明确的合同。
性能和可靠性。在BC内部，可以选择合适的一致性模型和存储。外部-异步投影。

2）如何识别Bounded Context

1.事件风暴：将域事件"发生了什么"加起来,然后命令"要求做什么",然后加上"谁保证规则"。

2.语言集群：单词和规则始终重合的地方-潜在的BC。其中"客户"一词表示不同（付款人vs玩家）-存在明显不同的上下文。

3.不变量和ownership：什么不能被破坏,谁来回答?不变性→可以保证它的BC内部。

4.价值流：将经常改变在一起的步骤分组，这些步骤是一个卑诗省候选人。

5.组织结构：如果一个部分由具有单个KPI的单独命令完成，则可能是单独的BC（但反之亦然：组织结构不应盲目地决定模型）。

• 术语争议（"出价"，"票证"，"回合"-不同的含义）。
• 最热的不变量"流过"服务。
• 不同的SLO和变化速度。
• 为了原子性，模块之间的"双写"。

3）典型上下文（主题领域的示例）

Identity/KYC-注册、验证级别、约束状态。
Wallet/Ledger-资产负债表，电汇，储备，货币。
Betting/Orders-接收，报价，结算。
游戏/回合是回合的生命周期，结果。
Bonus/Promo-权责发生制，vager，转换。
Payments-存款/收款，支付网关状态。
Compliance/Reporting-报告、审计、监管展示。
Catalog/Provider Integration-游戏，版本，提供商状态。
Analytics/Read Models-投影和实例化视图。

4） Context Map： BC如何交互

• Customer–Supplier.一个BC（Supplier）提供事件/数据，另一个（Customer）调整其模型。
• Conformist.客户采用Supplier语言和模型（例如,监管注册表）。
• Partnership.两个BC同步演变语言和合同（通常是一个团队/路线图）。
• Shared Kernel.一般最低升降机/图书馆，共同考试；谨慎使用。
• Anti-Corruption Layer (ACL).保护层，将别人的模型翻译成自己的语言。
• Open Host Service / Published Language.公共协议/计划，经过审查和记录。

实践：默认情况下,使用ACL和异步事件；Conformist-仅当提供商规定标准时，Shared Kernel才是最低限度的和有意识的。

5）边界=语言+模型+不变量+存储

• Ubiquitous Language.带有示例的术语词典。
• 聚合和不变量。谁"持有"规则，允许哪些操作。
• 一致性模型。Strong/CP用于金钱，EC/causal用于店面。
• 存储和索引。选择不变量和SLO。
• 退出合同。事件/命令，方案版本，交付的SLO。

外部：没有直接SQL/表约束。沟通-通过合同。

6）边界与一致性（PACELC）

在BC内部：选择不变量的模型（接收处的Wallet-Strong，Betting-Strong）。
在BC之间：最常见的是事件和投影。如果需要同步检查-带有截止日期和不可用故障的显式命令（不是"隐藏"REST电话）。

7）反腐败层（ACL）

ACL任务：不要让别人的语言和"脏"数据进入卑诗省。

图解映射：外部"PaymentStatus=SETTLED" →内部"LedgerEntry（类型=信用，reason=PsPSettle）"。
验证和丰富：不变性验证，时区规范化，货币。
转化：支持"schema_version"外部合同，向后兼容性。
相同性：通过"external_id"/"operation_id"。
可观察性："有毒"消息的"源"，"schema_version"，"mapping_id"，DLQ。

8）边界和数据： 所有权，投影，API

Ownership：谁拥有"真相"？只有所有者更改记录。BC的其余部分是read模型和参考。
投影：读取下的非标准化表；从事件中更新。
API：命令（与所有者发生变异）和查询（阅读投影）。没有其他数据的"端到端"更新。

9）演变和版本

事件和API-具有"schema_version"和兼容性策略（additive+fallback）。
Blue/Green by BC：新合同"v2"平行于"v1"发布，流量逐渐转移。
迁移：对于重大变化-新的投影/服务，阅读的"两阶段卷轴"。

10）边界测试

合同测试：检查BC是否遵守已发布的合同（产品测试），并正确理解别人（消费者测试）。
基于属性的：BC内部的聚合不变性（平衡，限制，唯一性）。
集成上的混乱：延迟，订单外部，复制，计划进化；具有DLQ和安全的redrive。
NFR测试：p95/边界峰值负载 （事件服务器/ACL）。

11）可观察性和SLO边界

度量标准：通过事件/命令、'projection_lag_ms'、'dlq_rate'、mapping错误、p95 API。
Tracing：强制性标签'bc'、'tenant_id'、'event_id'、'operation_id'、'schema_version'。
Alerts：投影滞后，命令故障增加，方案"flap"（许多"schema_mismatch"）。

12） multi-tenant和地区

"tenant_id"-在边界上所有事件和投影的键中。
Fairness： 发布限制/redrive per tenant以使"嘈杂"不会破坏邻居的SLO。
居住地：卑诗省的数据生活在"家庭"地区；跨区域汇总/报告。

13）反模式（由模糊的边界引起）

巨型"核心服务"。每个地方都→事务斗争，长版本，低自主权。
表集成。直接选择到别人的表→脆弱性,并在模式下进行配对。
Dual-write.同时"方便"地写成两个BC，→发散和不变量的破坏。
默认的Conformist。"采用别人的模式"→别人的含义被泄露，进化是不可能的。
隐藏同步呼叫。REST的"内部某个地方"没有明确的合同和截止日期→出乎意料的可用性依赖性。

14）轮廓示例（语言方案）

[Wallet/Ledger] <--CP, Leader, Transactions-->
publishes: WalletReserved/Committed v
[Betting] <--CP on bid taking-->
events: BetPlaced/Settled v
[Read Models/Analytics] <--EC projection-->

[Payments] --ACL--> [Wallet/Ledger]
[Provider Integration] --ACL--> [Game/Round]
[Compliance] <-events - [KYC/Identity], -> reports [Reporting]

15）边界选择迷你海德

1.形成不变量并确定谁可以保证它们。
2.描述字典（10-20个术语）,并检查团队是否有一种理解。
3.绘制Context Map和关系类型。
4.解决内部和连接上的一致性模型。
5.设计合同（事件/命令）和ACL。
6.规划可观察性（度量/tracing/alerta）和DLQ/redrive。
7.进行合同测试和"风暴"（chaos）以进行集成。
8.确定政府：谁会说语言/方案，如何进行更改。

16）售前支票清单

• 每个BC都有字典，汇总和不变量。
• 在Context Map上定义了关系并记录了合同。
• 通过事件/命令和ACL进行集成,没有直接SQL依赖关系。
• 指挥/事件的相等性；有outbox/inbox和DLQ。
• 一致性模型（BC内部/之间）已提交并测试。
• 电路转换和互操作性策略（v1/v2）。
• Laga/Error/Performance和Alerta度量标准已配置。
• 遵循多重性和数据驻留政策。
• 操作花花公子：schema-mismatch, redrive, rebuild投影。

17）快速食谱

金钱和限制：带有CP和交易的单个BC，仅限命令API，事件作为读取真理的结果。
Fids/目录：带有EC的BC，投影和缓存，显然是"新鲜"。
与外部提供商的集成：始终通过ACL、事件/命令、模式转换。
团队成长：一个BC是一个团队，团队具有"语言所有者"和"不变量守护者"。
重构整体：首先是合同和ACL,然后是物理分离。

结论

Bounded Context不仅是图表，而且是关于语言，规则和演变方法的工作约定。清晰的边界减少了连通性，加快了变化，并使系统可预测地运行。根据含义和不变性进行划分，保护ACL边界和合同，使用所有指标进行测量-即使域和团队快速增长，您的体系结构仍将保持灵活和可靠。