Lesson 0044 · Initiative Lead · Module 2
Draw the Context, Then Choose Boundaries
The valuable architecture diagram is not the most detailed one. It is the smallest view that lets its audience inspect a decision.
Mission tie-in: system design turns drivers and workflows into boundaries with controlled dependency direction. Diagrams are review instruments, not wall art.
Knowledge: three views, three questions
Start with a system context view: the system in scope, the people who use it, and external systems it touches. This answers what is ours, who needs it, and where are the external dependencies and trust boundaries?
Then draw a container view—C4's word for a deployable application or data store, not specifically Docker. This answers what runs, what stores data, how do they communicate, and who owns each part? Finally, draw one dynamic view for the risky workflow. This answers what happens in time when the happy path or failure case runs?
| View | Elements | Decision exposed |
|---|---|---|
| Context | customer, support agent, returns system, order platform, carrier, payments | Scope, actors, external ownership, PII and trust crossings |
| Container | existing web app, returns module, existing database schema, background worker | One deployable plus worker; no new service fleet |
| Dynamic | request → decision → persisted intent → label attempt → notification | Carrier failure cannot lose the accepted request |
For a 6–8 person cross-functional team, a modular monolith is the responsible default: one deployable, explicit modules, one composition root, and enforced dependency rules. It minimizes coordination and operational surface while preserving seams. Choose another deployable only when a driver requires independent scaling, isolation, security, availability, release cadence, technology, or ownership—and record the cost.
Inside the deployable, draw modules around four kinds of evidence:
- Language: eligibility, journey, and settlement mean different things.
- Change: policy changes weekly; carrier integration changes on vendor cadence.
- Invariants and state: the eligibility decision must be internally consistent.
- Ownership: one owner can change a module without negotiating every edit.
Keep technology at the edges, as lesson 0023 established. The domain-facing interface says create_label(intent), not carrier_sdk.shipments.post(payload). On the diagram, label every arrow with the interaction and protocol. Unlabelled arrows conceal assumptions.
A diagram should carry a title, scope, audience, date/version, legend, ownership, and the significant qualities or risks it addresses. Delete boxes that do not help the stated audience make a decision. Code-level detail belongs in code unless it explains an unusually important mechanism.
| You see | What it hides | The move |
|---|---|---|
| one diagram with 70 boxes | Audience and decision are undefined. | Split by scope and question. |
| arrows without labels | Protocol, direction, and meaning. | Name every interaction. |
| database shared by “services” | State ownership is fictional. | Name the writer or merge boundaries. |
| a service per domain noun | Deployment cost has no driver. | Return to workflow and change. |
Skill: draw only what earns its place
A context diagram primarily establishes:
When should this team add a service?
The critical dynamic view should show:
Practice: make a three-view architecture packet
Draw a context diagram, a container diagram, and one dynamic diagram for your riskiest workflow. On each: state audience and question; label every boundary, owner, arrow, and data store; annotate which driver it addresses. Run a review where every comment must point to a driver, workflow, or risk.
Reveal: the service-extraction test
Before extracting a deployable, complete this sentence: “We accept network failure, versioning, deployment, observability, security, and on-call overhead because independent _____ is required by driver _____.” If the blanks contain “cleanliness” or “maybe later,” keep a module seam and postpone the distributed system.
Your win
You can communicate system scope and runtime behavior, choose evidence-based module boundaries, and resist deployment boundaries whose costs have no driver.
Read and watch deeper
- The C4 model, Simon Brown — official model; especially context, container, dynamic diagrams, and notation checklist.
- Fundamentals of Software Architecture, Richards & Ford — architecture styles, characteristics, and component boundaries.
- Team Topologies, Skelton & Pais — ch. 6–7: aligning ownership boundaries and interaction modes.
- Reference: Initiative Playbook · architecture packet, and deep modules.
Show the diagrams to your agent-teacher with the driver set and ask which box or arrow has no justification and which driver has no visible response.