The Three Pillars of Domain-Driven Design

Domain-Driven Design is an approach for delivering software, and it's focused on three pillars:

1. Ubiquitous Language: Domain Experts and software developers work together to build a common language for the business areas being developed. There's no us versus them; it's always us. Developing software is a business investment and not just a cost. The effort involved in building the Ubiquitous Language helps spread deep Domain insight among all team members.
2. Strategic Design: Domain-Driven Design addresses the strategy behind the direction of the business and not just the technical aspects. It helps define the internal relationships and early warning feedback systems. On the technical side, strategic design protects each business service by providing the motivation for how an service-oriented architecture should be achieved.
3. Tactical Design: Domain-Driven Design provides the tools and the building blocks for iterative software deliverable. Tactical design tools produce software that is not only correct, but that is also testable and less error prone.

Ubiquitous Language

Along with  Chapter 12, Integrating Bounded Contexts, Ubiquitous Language is one of the main strengths of Domain-Driven Design.

In Terms of Context
For now, consider that a Bounded Context is a conceptual boundary around a system. The Ubiquitous Language inside a boundary has a specific contextual meaning. Concepts outside of this context can have different meanings.

So, how to find, explore and capture this very special language, the following pointers would highlight the same:

• Identify key business processes, their inputs, and their outputs
• Create a glossary of terms and definitions
• Capture important software concepts with some kind of documentation
• Share and expand upon the collected knowledge with the rest of the team (Developers and Domain Experts)

Since Domain-Driven Design was born, new techniques for improving the process of building the Ubiquitous Language have emerged. The most important one, which is used regularly now, is Event Storming.

Event Storming

Alberto Brandolini explains Event Storming and its advantages in a blog post, and he does it far more succinctly than we could.Event Storming is a workshop format for quickly exploring complex business domains:

• It is powerful: It has allowed me and many practitioners to come up with a comprehensive model of a complete business flow in hours instead of weeks.
• It is engaging: The whole idea is to bring people with the questions and people who know the answer in the same room and to build a model together.
• It is efficient: The resulting model is perfectly aligned with a Domain-Driven Design implementation style (particularly fitting an Event Sourcing approach), and allows for a quick determination of Context and Aggregate boundaries.
• It is easy: The notation is ultra-simple. No complex UML that might cut off participants from the heart of the discussion.
• It is fun: I always had a great time leading the workshops, people are energized and deliver more than they expected. The right questions arise, and the atmosphere is the right one.

If you want to know more about Event Storming, check out Brandolini's book, Introducing EventStorming.