Learning Domain-Driven Design

Domain-driven Design (DDD) provides a set of practices for a collaborative approach to building software from the perspective of the business—that is, the domain, and its problems that you are targeting.

The author suggests that DDD is one approach to solving the software crisis, in which approximately 70% of software projects fail to be on time, on budget, or meet the client’s requirements. I wonder how that will change now that we have AI Agents writing most of our code. However, DDD promises to solve that root cause of the crisis, which is communication, whether that is team communication, unclear requirements, unclear goals, etc.

The goal of DDD is to write software that reflects the business domain, so the name in full is: (business) domain-driven (software) design.

To understand the problem, you have to understand the context within which it exists—the organization’s business strategy, and what value it seeks to gain by building the software.

I agree completely and it’s why I find my degree in Entrepreneurship so valuable.

To start with DDD you first need to determine what the domain of the business is (e.g. UBER = delivery) and the core subdomains (fleet management, user mobile app, driver app, online payment system). After determining the domain, you need to work with the domain experts to understand how the business works, these would be like key stakeholders in the organisation, and the software needs to solve their problems.

It’s developers’ (mis)understanding, not domain experts’ knowledge, that gets released in production. – Alberto Brandolini

To be effective, software has to match the mental models of the domain experts, not the software developers. To be effective, it should be a collaborative effort with clear communication. Agreement and alignment of the problem and project are essential to the project’s success. Using ubiquitous language is the cornerstone of DDD, that is language which is simple and straightforward… everyone needs to speak the same language. There is no point in talking to a domain expert about singletons and design patterns.

• Be consistent
• Remove ambiguous terms: insurance contract not policy
• Remove interchangeable terms: a user could be a visitor, administrator, reviewer
• Maintain a shared glossary or wiki of terms to help onboard new team members

Also note that mental models and language may be different across subdomains, and they might not understand each other’s problems or needs. The solution to this is to create bounded contexts and logical separations. In software development terms, this means use micro-services for each domain, or create folders for each domain in the monolith:

src/
    Features/
        Authentication/
        Billing/
        Drivers/
        Fleet/
        Insurance/

In the Laravel world, each one of these folders would have its own models, controllers, contracts, etc.

Use contracts to ensure that models or other touchpoints in various bounded contexts can work together.

There is a chapter on database transactions and active records which seems a bit out of place, this is something that’s just a normal part of everyday life in the Laravel ecosystem.

There is a chapter on models which also seems a bit basic.

Then there is a chapter on event sourcing…

The first half of the book was really strong and insightful but the second half is letting it down, and it seems like it’s just explaining common-sense programming techniques that don’t really relate to DDD.

Next, the author talks about brainstorming or “event storming” which is just fancy brainstorming with snacks:

1. Unstructured Exploration: create sticky notes for all domain events
2. Timelines: organise the events into a timeline
3. Pain Points: identify bottlenecks, delays or other issues
4. Pivotal Events: identify significant state changes, i.e. order initialized -> order shipped
5. Commands: identify the triggers, i.e. “submit order”, or “cancel order” that trigger other event flows
6. Policies: identify the triggers that fire or should without user involvement, i.e. VIP User -> upgrade order
7. Read Models: these are views of data that is available when actors make a command, i.e. shopping cart data
8. External Systems: identify systems not part of the current domain context boundary
9. Aggregates: identify or add aggregates that receive commands and produce events
10. Bounded Contexts: group aggregates to help create natural bounded contexts in the system

In the real world, the author suggests it will be more messy to do this work than you expect.

I think this book has a problem because it’s trying to address two different audiences… if you’re a software developer the second half of the book isn’t even worth reading and it seems like it has nothing to do with domain-driven design at all. Or the book is not designed for software developers? It doesn’t really make sense. It had a lot of potential but didn’t live up to it.