Domain Driven Design in practice - how to draw your domain boundaries IRL - Vilde Opsal

Domain design is an art, not a science - there are no “perfect” domain boundaries, but rather choices that need to be made by individuals rather than committees

Meet stakeholders where they are - tailor domain map presentations and visualizations to different audiences (tech leads, business people, product managers) and their specific needs

Use iterative versioning and refinement of domain maps - start simple and reveal/evolve details over time rather than trying to create a perfect map upfront

Domain boundaries should enable team autonomy and independent work while still aligning with business strategy and organizational context

One team per domain is recommended (teams shouldn’t share domains), but a single team can maintain multiple related domains

Domain maps need to balance technical, business and organizational contexts - no single view works for all stakeholders

Use visualization techniques like whiteboards, floor plans and simplified diagrams to make domain concepts more accessible to different audiences

Domain boundaries can and should evolve over time as business needs and organizational structure changes

Get early feedback by sharing incomplete/draft domain maps rather than waiting for a fully polished version

Focus on making the domain model click with stakeholders’ mental models - if people don’t understand it, the map won’t be effective regardless of technical accuracy

Domain ownership decisions should be made by architects/technical leaders while getting input from all stakeholders

Use versioning and iterative refinement to evolve domain maps over time rather than trying to get them perfect initially