Chapter 26 — Deliver a Reviewable Fulfillment Control Plane
Chapter objective: After this chapter, a developer can run the book-owned fulfillment control plane, connect all three collection types to fault experiments, observation signals, and evidence levels, and make a bounded release decision.
Learning objectives
- Trace from a business contract to a DSM adapter without exposing collection APIs to business code.
- Accept normal paths and failure windows for Register, Lease, and CRDT together.
- Re-run book, example, observation, security, lifecycle, federation, real-port, and publication evidence with one script.
- State what can be released and what still needs deployment validation.
Prerequisites
- Chapters 1–25 are complete.
- Java 25, Maven/Wrapper, and Node.js 22+ are available.
- DSM
0.1.2is installed in the local Maven repository, or a full DSM build runs first.
Case progress
The fulfillment control plane publishes healthy routes, claims
shards, and counts accepted requests. Business code depends only on
FulfillmentCoordination; DsmFulfillmentModule
owns Runtime, locators, codecs, and typed handles inside the composition
root.
Acceptance follows a chain
| Layer | Acceptance question | Return on failure |
|---|---|---|
| business contract | Does the caller see route, claim, count, uncertain, and fencing only? | domain port and invariant |
| collection adapter | Does each collection express the intended state? | locator, codec, and collection choice |
| fault experiment | Are concurrency, partition, loss, and repair outcomes explicit? | failure contract and external guard |
| operating responsibility | Can the system diagnose, reject untrusted messages, and ready/stop correctly? | Arc 5 operating contracts |
| evidence level | On which execution surface was each claim validated? | traceability matrix and command |
Final realization of DSM's value
The capstone compresses the book into one executable path. Domain ports express route publishing, shard claiming, and request counting. The DSM adapter reuses Register, Lease, CRDT, propagation, and repair. Tests and observation surfaces state the execution environment in which each mechanism holds.
Business teams avoid rebuilding these coordination foundations in every service while retaining responsibility for order facts, external fencing, partition-time response policy, and target-environment acceptance. A learner completes the path by selecting or rejecting DSM from an invariant, running normal and fault experiments, explaining observations, and converting uncovered scope into deployment tasks.
Normal path is not final acceptance
The book Maven example validates a domain fake and real standalone Runtime. DSM integration validates multi-node propagation, repair, security, and federation. The Redis-shaped example validates real ports. Together they still leave production networking, external transactional fencing, deployment drain, and capacity SLA open.
One-command acceptance
node scripts/verify-capstone.mjsThe script runs serially so Maven reactors do not share
target directories concurrently. It stops on the first
failing command and names every evidence layer. Finally it re-exports
Draw.io diagrams and builds both online editions and PDFs so content and
publications share one candidate state.
Release-decision template
Confirmed: On pinned revisions, the domain-port boundary holds; all three collections run; controlled multi-node propagation/repair, security/federation, and loopback RESP tests pass; chapter assets, links, diagrams, and publication builds are reproducible.
Deployment acceptance still needed: production topology, cross-host networking, external-store fencing, metrics backend/on-call process, key custody, real drain, data scale, peak repair, capacity, and disaster recovery.
Every open item has an owner, environment, command/probe, threshold, and failure response. A book green result cannot close it.
Counterexample and fault injection
- Change an asset without its manifest, or return
DsmRegisterfrom business code, and observe gates reject evidence drift or technical-type leakage. - Turn loopback Redis evidence into a cross-host production claim, or
run Maven reactors against shared
targetdirectories in parallel, and observe boundary review or serial gating prevent a false green.
Experiment
- Run
node scripts/verify-capstone.mjs. - Check each claim, evidence item, and boundary in
capstone-acceptance.json. - Create a separate acceptance card for the target deployment; the book card does not establish production completion.
Experiment acceptance card
| Field | Content |
|---|---|
| Command | node scripts/verify-capstone.mjs |
| Input or fault | three collections, domain port, repair/security/lifecycle/federation, real RESP socket, and publication pipeline |
| Observable result | all pinned evidence passes serially; a failing command exits nonzero; boundary card is complete |
| Evidence level | Combined E1–E4 selected per claim, without applying the highest level to every conclusion |
| This experiment does not prove | Target organization and production environment have approved release |
Review
- Delivery is a chain of business contract, runtime implementation, fault experiment, evidence, and boundary.
- One script improves reproducibility without raising evidence level by itself.
- Every release decision binds revision, environment, and open claims.
- Completion means both buildable modules and a learner who can reproduce experiments and make a boundary-consistent decision.
Next
Use the appendices for APIs, Spring properties, troubleshooting, terminology, and evidence. When the DSM revision changes, Appendix E identifies chapters requiring review.