Lesson 0041 · Initiative Lead · Module 1
Map the Workflow Before the Components
The fastest route to a bad architecture is to turn nouns in a brief into tables and services. Start with what happens, who decides, and where the work breaks.
Mission tie-in: good boundaries follow behavior, language, policy, and ownership. Workflow discovery supplies the evidence that folder trees and system diagrams cannot invent.
Knowledge: behavior before structure
For the returns initiative, a noun-first design finds Return, Customer, Label, and Refund, then draws a service around each. A workflow tells a different story:
Return requested → order verified → policy interpreted → evidence requested → eligibility decided → label created → parcel received → refund authorized → customer notified
Actors: customer, support agent, policy owner, warehouse clerk. External systems: order platform, carrier, payments. Hotspots: policy interpretation, missing evidence, warehouse-to-refund handoff.
Build this with the people who do the work, not only their managers. Ask for the last real case, including spreadsheets, copied identifiers, manual messages, exceptions, and waiting. The “unofficial” steps often contain the actual domain rules.
A lightweight EventStorming sequence helps a cross-functional group uncover the model:
- Write domain events—facts that happened—in past tense and order them.
- Add commands that caused them and the actors who initiated those commands.
- Add policies: “when parcel received, authorize refund if inspection passed.”
- Add external systems, time, manual steps, questions, and failures.
- Mark hotspots where language, rules, responsibility, or confidence changes.
Those hotspots are design evidence. “Approved” means policy eligibility to support, warehouse inspection to operations, and settled money to finance. One global status would collapse three models. The workflow suggests separate states and a translation boundary, just as lesson 0036 predicts.
Map the current state before the desired state. Otherwise the team will unknowingly preserve invented steps and miss real constraints. Then design the target workflow by removing waiting, duplicate entry, and decisions the system can safely make—not by automating every current step.
| Listen for | It reveals | Capture as |
|---|---|---|
| “Usually, except when…” | A policy and its exceptions. | Rule plus counterexample |
| “Then we wait for…” | A dependency or missing event. | Time and external owner |
| “Approved means…” | Competing domain meanings. | Vocabulary boundary |
| “I keep a spreadsheet…” | Unserved state or coordination. | Manual system of record |
Skill: read design evidence from a workflow
Why begin with domain events?
Two teams use “approved” differently. This signals:
Why map the current state first?
Practice: tell one real story end to end
Invite one domain expert, product, design, and two engineers. Map a recently completed real case as events. Add commands, actors, policies, external systems, waiting time, manual work, failures, and vocabulary collisions. Finish by writing three candidate boundaries and the evidence for each—do not draw deployables yet.
Reveal: candidate boundaries from the returns map
Eligibility owns policy interpretation and a decision with reasons. Return journey owns customer-visible progress and communication. Refund settlement belongs to the existing payments context. These are model boundaries, not necessarily three services: a modular monolith can enforce all three while one small team owns the initiative.
Your win
You can use a real workflow to discover domain language, rules, waiting, external dependencies, and candidate boundaries before committing to data models or deployables.
Read and watch deeper
- Introducing EventStorming, Alberto Brandolini — the canonical guide to events, commands, policies, hotspots, and collaborative modeling.
- User Story Mapping, Jeff Patton — ch. 3–5: tell the whole story and build shared understanding through activity.
- Domain-Driven Design, Eric Evans — ch. 2 and 14: ubiquitous language and maintaining model integrity.
- Reference: Initiative Playbook · workflow map, and glossary: bounded context.
Give an anonymized workflow transcript to your agent-teacher and ask it to extract events, commands, policies, ambiguities, and missing actors; validate every extraction with the domain expert.