Introduction to Domain-Driven Design

Gerson Sunyé gerson.sunye@univ-nantes.fr

Introduction

Tackling Complexity in the Heart of Software

domain driven design evans

Eric Evans, 2003

The basis

  • Putting the Domain Model to Work

  • The Building Blocks of a Model-Driven Design

  • Refactoring Toward Deeper Insight

  • Strategic/Tactical Design

Implementing Domain-Driven Design

implementing domain driven design vernon

Vaughn Vernon, 2013

Putting it to work

  • More examples

  • Technical details

  • More patterns

2003, The Dark Age of Software Development

  • Java (v. 5.0) and only Java

  • J2EE

  • EJBs

  • SQL Databases (and only SQL)

  • O-R Mappers

When the technology becomes more complex than the domain, developers' view is shifted
java logo

Domain-Driven Design

  • Set of ideas, principles and patterns focusing to design effort

  • Assists software developers in designing and implementing software that delivers high value, both strategically and tactically

  • Relies on the idea of a very tight coupling between a model of the domain, such as an activity diagram or use case, and the software

  • Invites developers to learn the domain vocabulary and use it to communicate

Not a technology or a development method

Benefices of Domain-Driven Design

  • Creates a common, shared language between the domain experts, the software developers, and the software, without requiring translations:

    • The Ubiquitous Language

  • Facilitates a creative collaboration between domain experts and technical experts (developers), to produce software with high value for the business

  • Results in software that is built for change

Domain-Driven Engineering Today

New Domains of Application

  • Microservices

    • Decomposition strategy

  • Frontend Development

Active Community

  • DDD Europe

  • DDD Academy

  • etc.

Background

Traditional Software Development Issues

  • Developers and domain experts talk in different languages, making it difficult for them to understand each other and collaborate

  • Developers misunderstand how the business operates, resulting in inadequate software

  • Technical details leak into the software model

  • Changes to the software take are more time consuming and code breaks easily when changes are made

The Software Developer and the Domain Expert

software developer
Figure 1. The Software Developer

Oldfag geek by rones

domain expert
Figure 2. The Domain Expert

Filosofo by Hack-Master

The Software Developer

software developer
Figure 3. The Software Developer

Oldfag geek by rones

  • Is narrow-minded, strict to the principles

  • Loves new techniques and tools

  • Knows what techniques can be used to make great and extensible software.

The Domain Expert

  • Is interested in creating value for the business

  • Can talk endlessly in great details about his vision and his knowledge on the problem domain

domain expert
Figure 4. The Domain Expert

Filosofo by Hack-Master

Scope

Is it suited for all kinds of applications?

  • Quick answer: No!

    • If your application is only CRUD, it is overkill

  • Elaborated answer:

    • DDD proposes several patterns and principles

    • Some of them may be useful, when used in isolation

Example: Twitter

  • In 2019, 145 millions of active users, producing 500 millions of message per day.

  • A very simple domain model

Twitter Domain Model
Figure 5. Twitter Domain Model

Where is the complexity?

Principles: The Domain Model

Domain

Domain

Noun. A sphere of knowledge or activity.
What an organization does and the world it does it in.

— Cambridge Dictionary

  • An arbitrary boundary around some subset of concepts in the universe

  • In general, refers to an organization business problem

  • Subjective concept

Model

Model

A simplified representation an aspect of the world, for a specific purpose

  • In our case, the domain is the aspect of the world

  • The model is distilled from the domain knowledge

Model Example

mercator world map
Figure 6. Map of the world in Mercator projection

Janwillemvanaalst, CC BY 4.0, via Wikimedia Commons

Another Model

earth
Figure 7. A composite image of the Western hemisphere of the Earth

NASA/ GSFC/ NOAA/ USGS, Public domain, via Wikimedia Commons

Models must be Useful

If you want to navigate from Nantes to Recife, which one would you chose?



Models serve a purpose. Otherwise, they are useless.

Tight Coupling between the Model and the Software

  • A change in one implies a change in the other:

    • if the model of the domain changes, the software also changes.

  • The reverse is also true:

    • if the software changes, the model must change.

Changing One without the Other

  • Changing only the model means the software gets left behind as the understanding of the domain evolves.

  • Changing only the software calls into question the relevance of the software to the user’s needs.

  • The model and software influence each other through several iterations and need to evolve together.

Domain Vocabulary

  • In DDD, the vocabulary of the domain is used everywhere: conversations about the software, in diagrams, class names, method names, and variable names.

  • When a set of words means the same thing to everyone on a project, communication is easier.

    • Misunderstandings happen less often.

  • Concepts in the domain map directly into the code

    • It is easy to look at the code and understand what is going on.

  • Code maintenance is easier

    • You can figure out where to look to do a bug fix or an enhancement.

Domain Modeling

Why should computer scientists bother to learn about a domain?

  • Writing good software requires an understanding of what the user needs and the problems they’re trying to solve.

  • Forcing users to map their domain into something different raises their learning curve and makes them less productive.

    • In the worst-case scenario, they get frustrated with your software, stop using it, and tell all their friends and bosses about their bad experience.

Software Engineers, not Domain Experts

I’m a Doctor, not an engineer!
Star Trek
— Dr. Leonard McCoy

  • We are software engineers, not experts in another domain.

  • However, if you learn enough to meet a user on their context and understand how to solve the problems they face in a way that makes sense to them, you will have written good software that helps them.

Understanding the Domain

— Wait! I didn’t sign up for this!

  • Learning about a domain can feel messy, not very relevant, and frustrating.

  • That’s normal, but it’s also a great opportunity.

  • If you like to learn, writing software is a way to sample what other domains are like.

    • You may discover that the domain is more interesting than you thought!

Applying DDD

  1. Find a domain expert. Talk with them and learn the vocabulary of the domain.

  2. Work with the domain experts to develop a model of the concepts in the domain and how they interact. The model can be textual, like a use case, but diagrams are often easier for people to understand. Use the vocabulary you have learned in the first step.

  3. Keep iterating with the domain experts on the model until you have a clear understanding of the problems the user needs you to solve.

  4. Translate the model into code with DDD practices. If you need to implement something different from the model, revisit the thinking for the model and change one or the other to keep them in agreement.

Explanatory Models

  • This example relates to shipping things overseas.

  • Which diagram do you think is easier to understand for someone who knows about shipping?

  • This one?

cd shipping route
Figure 8. Class Model for a Shipping Route [Evans]

  • Or this one?

em shipping route
Figure 9. Explanatory Model for a Shipping Route [Evans]

Explanatory Models

  • The diagram on the previous slide is an explanatory model.

  • It doesn’t have a format - the important part is to establish a way that you and the domain expert can connect with a shared vocabulary.

Be creative! If the diagram is easily understandable, the diagram is correct.

Design Principles

Strategy and Tactics

Strategy without tactics is the slowest route to victory.
Tactics without strategy is the noise before defeat.

— Sun Tzu (544-496 BC)

Strategic and Tactical Design

Strategic design

Modeling and design decisions that apply to large parts of the system.

Tactical design

Modeling and design decisions that apply to the implementation of a smaller part of the system.

Strategic Design

  • Splitting up a large domain model and focusing development effort on what is strategically important for the business (the core domain).

Tactical Design

  • Building a rich domain model that reflects our mental model and the ubiquitous language

Strategic Patterns

strategic patterns

Tactical Patterns

tactical patterns

Principles: Architecture

Layered Architecture

layered architecture

Layers

Domain Layer

Entities, Aggregates, Aggregate Roots, Value Objects, Repositories, Domain Services, Domain Events, Policies

Application Layer

Application Services, Data Transfer Objects (and their Validation), Unit Of Work, Authorization, Auditing…

Infrastructure Layer

Persistence, Sending Emails, Dependency Injection, Logging, Caching implementations…

Presentation Layer

Web, Mobile… specific technologies and tools

Conclusion

Summary

  • Strategic design helps splitting up a large domain model and focusing on the most important part

  • Tactical design helps creating a rich domain model that captures business logic

  • The ubiquitous language is used by all team members to prevent having to translate between technical and domain terminology

Conclusion

  • DDD is a good strategy on how to collaborate with users and write maintainable software.

  • Not all DDD concepts will map to the problem you’re trying to solve - don’t apply a DDD concept where it doesn’t seem to fit.

  • DDD is another tool to have in your software development toolbox. Have it ready to use when it seems right to use it.

References

  • [] Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans. Addison Wesley, August 20, 2003.