From Domain Boundaries to Software Architecture - Maxime Sanglan-Charlier

Core message

To enable independent, fast‑flowing teams you need both organizational alignment (value streams / stream‑aligned teams) and a loosely coupled software architecture that maps to domain subdomains. Achieving this requires identifying, refining and validating domain boundaries through collaborative techniques — not by one‑off rules or a rigid recipe.

Teams + boundaries + collaboration = sustainable, evolvable architecture

Key techniques, tools and workflows

1. Event Storming (big‑picture and detailed)

   • Collaborative workshop using orange post‑its arranged left → right on a timeline and phrased in past tense (domain events).
   • Invite cross‑discipline participants (developers, product, testers, customer support, accountants, etc.) to reveal different perspectives.
   • Run high‑level sessions to propose candidate boundaries, then follow with detailed sessions to flesh out scenarios and edge cases.
   • Optionally annotate events with metrics (frequency / severity) using colors.

2. Heuristics to identify subdomains from an event storm

   • Treat each step in a process as a starting subdomain candidate.
   • Identify horizontal (shared) concerns that should be separate (example: notifications).
   • Look for semantic/name differences — the same real‑world entity called different names in different contexts (e.g., “lead” vs “rider”) often signals distinct purposes/subdomains.
   • Be suspicious of generic names (e.g., “Management”) — they tend to accumulate mixed responsibilities.

3. Domain Message Flow Modeling

   • Choose reference scenarios (user stories / important flows) and model messages (commands / events / queries) between actors and subdomains.
   • Visualize payloads and interactions to spot smells: too many synchronous queries, components that merely pass through commands, hidden dependencies.
   • Use the visual models to compare alternative designs (copy / paste / edit) and to challenge assumptions.

4. Bounded Context Canvas

   • A canvas to turn fuzzy boundaries into a clearer design artifact: name, purpose, strategic classification, roles, messages in/out, domain terminology, and business rules.
   • Helps reveal cohesion issues, conflicting responsibilities, and where to split or merge subdomains.
   • Treat the canvas as a design snapshot (not mandatory long‑lived documentation); capture it in ADRs if helpful.

Architectural and organizational guidance

• Coupling assessment: use a practical “coupling pain” view — consider:

  • Strength (how much integration effort is required),
  • Volatility (how often parts change),
  • Distance (cascading impact of changes). Use these to prioritize which dependencies to remove or tolerate.

• Iterate and refine: follow cycles of modeling, scenario testing, and experimentation (Evans’ whirlpool‑style exploration). Expect to be wrong at first and plan to evolve.

• Collaboration is the multiplier: these techniques spread domain knowledge and design skills across teams so continuous evolution is possible.
• Documentation advice: prefer short‑lived design artifacts and code‑generated / living documentation where practical. Keep canvases as snapshots in ADRs if useful.
• Organizational change: architecture and team structure influence each other (see Team Topologies). Sometimes the right solution is to reorganize teams so dependencies disappear or become manageable.

Concrete examples & case studies used

• E‑scooter domain: identified subdomains such as Searching, Journey (ride), and Ride Completion via event storming.
• Car pickup/dropoff: reviewed events and questioned whether “give new owner a guide” belonged in that subdomain.
• Online order flow: Shopper → Sales (order placed) → Billing (payment collected) → Notifications — an illustration of message flow modeling.
• Accounting fixed assets: iterative refinements moved from many fine‑grained subdomains to a more pragmatic grouping based on behaviors and cohesion.

Practical tips & takeaways

• Start with important reference scenarios and validate boundaries against them.
• Visualize alternatives and discuss concrete message flows — “you don’t discuss what isn’t visualized.”
• Use the bounded context canvas as a decision aid rather than heavy documentation; capture snapshots in ADRs if desired.
• Add metrics where they clarify priorities (e.g., whether an edge case is rare or common).
• Prepare for and design for change; ensure teams whose responsibilities are split can collaborate closely to fix mistakes.

Resources and recommended followups

• Event Storming — Alberto Brandolini (workshops and materials)
• Domain Message Flow Modeling — templates on DDD Crew GitHub
• Bounded Context Canvas — canvas templates (including newer expanded versions)
• DDD Crew GitHub repository — cheat sheets and examples
• Team Topologies — for team design and stream‑aligned teams
• Eric Evans’ modeling / whirlpool exploration ideas (Domain‑Driven Design)
• Living documentation approaches — generate docs from code where possible
• Community resources: virtualdd.com and the New Crafts conference

Main presenters / sources

• Presenters: Maxime (Maxime Sanglan‑Charlier) and Nick (consultant co‑presenter).
• Key referenced sources: Eric Evans (DDD), Alberto Brandolini (Event Storming), Team Topologies, and DDD Crew (GitHub resources).