Visual reference for bounded contexts, team ownership, data boundaries, and migration paths.
This appendix is a visual study guide for boundary work. The goal is not to produce pretty diagrams. The goal is to choose a diagram that reveals one important architectural truth clearly: where responsibility sits, where data is authoritative, how workflows cross boundaries, where coupling is growing, or how a migration will unfold.
A good diagram should answer a concrete question faster than a paragraph can. A bad diagram hides the actual problem behind too many shapes, arrows, or labels. The examples below are deliberately simple so that the modeling pattern stays clear.
Use a context map when the main question is:
This diagram type is strongest early in decomposition work, especially when terms such as customer, order, or account mean different things in different parts of the organization.
flowchart LR
C["Catalog context"] --> O["Ordering context"]
O --> B["Billing context"]
O --> F["Fulfillment context"]
F --> W["Warehouse context"]
W -. "anti-corruption layer" .-> F
What this helps you see:
A context map is weak when teams turn it into a deployment diagram. Its job is conceptual boundary clarity, not runtime topology.
Use a dependency graph when the main question is:
This is often the fastest way to spot a distributed monolith pattern. If too many user flows pass through one node or if routine behavior requires a long chain of synchronous calls, the graph will show it.
flowchart TD
G["Gateway"] --> C["Checkout"]
C --> P["Pricing"]
C --> I["Inventory"]
C --> B["Billing"]
B --> N["Notifications"]
I --> R["Reporting"]
B --> R
What this helps you see:
This diagram is most useful when arrows mean something specific. If the diagram mixes synchronous calls, events, and ownership dependencies without distinction, it becomes noisy quickly.
Use a data ownership map when the main question is:
This type is especially valuable when service boundaries look clean in API diagrams but still depend on direct table reads, replicated truth, or read models that have become shadow authorities.
flowchart LR
C["Catalog service"] --> CDB["Catalog source of truth"]
O["Ordering service"] --> ODB["Order source of truth"]
B["Billing service"] --> BDB["Billing source of truth"]
CDB --> R["Search projection"]
ODB --> RP["Reporting projection"]
BDB --> RP
What this helps you see:
If a read model or reporting store starts being treated as authoritative, this diagram should make the violation obvious.
Use a sequence diagram when the main question is:
This is one of the best tools for testing whether a proposed boundary design survives real user behavior rather than only static modeling.
sequenceDiagram
participant U as User
participant C as Checkout
participant B as Billing
participant I as Inventory
U->>C: Confirm order
C->>B: Authorize payment
B-->>C: Authorized
C->>I: Reserve stock
I-->>C: Reserved
C-->>U: Order confirmed
What this helps you see:
Sequence diagrams are stronger than architecture-overview diagrams when teams are arguing about latency, ordering, or failure propagation.
Use a state or flow diagram when the main question is:
This is especially helpful for eventual consistency and saga discussions because it forces the team to name the in-between states honestly.
stateDiagram-v2
[*] --> Pending
Pending --> Confirmed: payment and inventory succeed
Pending --> ManualReview: timeout or ambiguous result
Pending --> Failed: compensation completes
ManualReview --> Confirmed
ManualReview --> Failed
What this helps you see:
If a team cannot draw the failure and compensation states clearly, it probably has not finished designing the workflow.
Use an extraction roadmap when the main question is:
This is one of the most useful diagrams for resisting big-bang rewrite thinking.
flowchart LR
M["Legacy monolith"] --> F["Facade or routing layer"]
F --> C["Extract catalog first"]
C --> O["Extract ordering later"]
O --> B["Extract billing after observability improves"]
What this helps you see:
Roadmaps are stronger when they include reasons for sequencing, not only arrows between boxes.
Use this kind of map when the main question is:
This helps connect architecture to operational reality, which is often where otherwise clean boundaries fail.
flowchart TD
T1["Commerce team"] --> C["Checkout service"]
T1 --> P["Pricing service"]
T2["Fulfillment team"] --> I["Inventory service"]
T3["Platform team"] --> PL["Tracing, CI/CD, identity"]
PL --> C
PL --> P
PL --> I
What this helps you see:
This diagram is especially useful during reorgs, incident review, and service catalog cleanup.
If the review question is mostly about meaning, use a context map.
If it is about runtime dependency or chattiness, use a dependency graph or a sequence diagram.
If it is about data and truth, use a data ownership map.
If it is about failure handling, use a workflow state map.
If it is about migration, use an extraction roadmap.
If it is about ownership and operations, use a responsibility map.
The fastest way to produce a bad architecture diagram is to ask one diagram to explain all of those things at once.
Use this quick checklist before trusting a diagram in a design review:
If the answer to those questions is weak, redraw the diagram with a narrower purpose.
A team brings one giant architecture diagram to a decomposition review. It mixes domain boundaries, API calls, events, databases, team ownership, and deployment topology in one page. No one can tell where the real problem is. What is the stronger correction?
The stronger correction is to split the model into purpose-specific diagrams. Use a context map for domain meaning, a dependency or sequence diagram for runtime interaction, a data ownership map for source-of-truth questions, and a responsibility map for team ownership. One overloaded diagram usually hides the exact trade-off the team is supposed to evaluate.