ARC 4接入真实业务工程第 15–18 章

第四篇回顾 —— 从集合 API 到业务工程（第 15–18 章）

业务层现在只依赖履约协调端口；DSM 的 locator、typed handles、Spring 装配与测试证据各自有明确归属。

工程边界

FulfillmentService
  → FulfillmentCoordination（业务端口）
    → DSM adapter（失败翻译）
      → composition root / Spring auto-configuration
        → Runtime + named typed handles

业务层可以用 fake 做快速决策测试，适配器仍需要在真实 Runtime 上验证。Spring Boot 只是另一种 composition root，不会改变 Register、Lease、CRDT 的语义。

四个不混写

不应混写	左侧职责	右侧职责
领域端口 / DSM handle	业务动作与结果	集合操作和技术失败
bean name / locator	当前容器选择 bean	分布式集合身份
clusterId/serviceId / locator	通信与同步域	集合与状态域
测试通过 / 生产就绪	固定执行面内的证据	部署、容量、安全与运维验收

本篇如何兑现 DSM 价值

第四篇把 DSM 的复用价值带入业务代码：领域端口隔离集合 API，composition root 集中 locator、codec 和生命周期，Spring Boot 负责可验证装配，多层测试限定结论范围。这样可以降低接入与演进成本，并避免 DSM 类型、身份和失败语义扩散到业务层。

可迁移检查表

业务 service 是否导入了 com.leanowtech.dsm.*？若是，先判断它是不是 composition root 或 adapter。
locator 是否只有一个事实源，并带 schema id？
Lease 结果是否保留 uncertain、reason 和 fencing token？
Spring 是否对重复 locator、缺 codec/merger 和非法 Lease 配置 fail fast？
集群/服务身份变更是否被当作协议迁移？
每层测试是否写出 proves 与 doesNotProve？

本篇证据

书籍自有示例提供 E1 领域端口和 E2 真实 Runtime 测试。
Spring auto-configuration 固定 Runtime、三类集合 bean、配置失败和生命周期。
Runtime integration 固定 locator 隔离、CRDT 和 Lease fencing。
TwoNode/Chaos 固定 E3 复制、repair 与分区行为。

下一步

第五篇不再扩展业务功能，而是补齐生产运行合同：可观测性、安全、生命周期和容量测量。