https://kevinwebber.ca/series/domain-modelling-in-practice/Latest chapters in Domain Modelling in PracticeHugoenTue, 05 May 2026 18:15:25 +0000https://kevinwebber.ca/series/domain-modelling-in-practice/part-3/Mon, 01 Jan 0001 00:00:00 +0000https://kevinwebber.ca/series/domain-modelling-in-practice/part-3/The previous parts introduced events, policies, commands, and aggregates as the building blocks of domain flow. Translating those flows into a system structure that can be built and maintained requires a different set of concepts. The flows tell us what happens. The structure tells us who owns what, where consistency is enforced, and how teams coordinate. Defining clear boundaries, both technical and organizational, keeps a system maintainable and scalable over time. Domain-Driven Design (DDD) provides three structural concepts for this purpose.https://kevinwebber.ca/series/domain-modelling-in-practice/part-2/Mon, 01 Jan 0001 00:00:00 +0000https://kevinwebber.ca/series/domain-modelling-in-practice/part-2/Event Storming is an interactive workshop that helps teams quickly develop a shared understanding of a business domain. By mapping out events, developers and business experts bridge their expertise, building a shared mental model that is clear enough to drive the design of an automated system. Take, for example, a financial service advisor. They understand the step-by-step process of opening an investment account, including key events that unfold. When paired with technical experts, this shared knowledge becomes a powerful tool for aligning software design with real-world processes.https://kevinwebber.ca/series/domain-modelling-in-practice/part-1/Mon, 01 Jan 0001 00:00:00 +0000https://kevinwebber.ca/series/domain-modelling-in-practice/part-1/ Your browser does not support the video tag. Learning about your systems by writing code is a very expensive way to understand and refine the business processes involved. Building software ultimately requires a group of people to come together and build complex systems using their unique talents. The first step is understanding reality, which is easier said than done when reality is a complex software system that spans multiple disciplines and teams.