A subdomain boundary can look sensible until a common business scenario crosses it. Domain Message Flow Modeling makes those crossings visible by sketching high-level messages between subdomains and their architectural subsystems. Its domain-oriented notation keeps the conversation in business language while staying close enough to implementation to inform architecture. section 12.2.2
Work through a flow collaboratively:
- Collect a concrete reference scenario, such as a sequence of domain events from big-picture EventStorming. section 12.2.2
- Walk through its events in order, sketching the interactions needed for each step. Ask domain experts to clarify what happens. section 12.2.2
- Challenge message types, names, and boundaries. In particular, ask whether a command or event changes which subsystem decides what happens next. section 12.6
- Revise the model rather than forcing a one-to-one copy of the original scenario. Favor a design that fits business needs; messy working diagrams are fine. section 12.2.2 section 12.2.3
Testing accounting-system boundaries
After big-picture EventStorming identified candidate subdomains for an accounting-system modernization, a group tested those boundaries against real use cases. Its first depreciation–fixed assets sales flow crossed four subdomains and required ten messages. Seeing that traffic prompted discussion: revaluation and sale occurred together in practice, so the group tried combining them into one subdomain. section 12.2.3
Inspect the first, fine-grained version of the accounting flow to see the boundaries and messages that prompted discussion. section 12.2.3
Compare the next version, which places revaluation and sales together, with the initial flow. section 12.2.3
Treat each flow as a test of the design, not a finished blueprint. Explore alternatives across multiple scenarios, then bring the findings together to check whether each subsystem’s messages and responsibilities still fit its purpose. section 12.6
