Summary of "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

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.
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.
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.
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).