1

Understanding

Domain-Driven Design

2

Domain-Driven Design Is …

… about developers and domain experts working

together to create software that is both

understandable and maintainable.

… a way to capture and spread knowledge using

shared models and highly readable and change

tolerant source code.

… gradually building a shared language between

developers and domain experts.

… a set of patterns and principles that can guide you

when doing software design.

… a great help in focusing your work. Domain-Driven

Design, or DDD, helps you understand where

sophisticated design really pays off, and where good

enough is good enough.

3

What Can DDD Do For Me?

☑ As a product owner, I like that Domain-Driven Design

helps us focus on the business issues and

opportunities we need to address.

☑ As an agile developer, I like that Domain-Driven

Design focuses on collaboration and high design

quality to achieve its goals.

☑ As someone who will also maintain the software, I

can see how we can use Domain-Driven Design to

create software that is easy to understand and

modify.

☑ As a domain expert, I appreciate being able to

quickly catch and correct misunderstandings about

the domain we work with.

☑ As a manager, I like how Domain-Driven Design helps

us codify and spread knowledge so that it’s shared

by more than one coworker.

4

When we work with Domain-Driven Design, we gradually build a

ubiquitous language. This is a language that can be found

everywhere, both in the source code and in the conversations

between developers and domain experts.

5

Domain

The domain is our trade, or sphere of activity. Example domains are

cargo shipping, financial derivatives trading and DNA matching.

Model

A model is a system of abstractions that describes selected aspects of a

domain. We use the model to solve problems related to the domain the

model describes. The model is implemented in the source code.

Ubiquitous Language

A language derived from the domain that is used when talking about our

model and software. It is used by both developers and domain experts as

they collaborate in the software project. Even the source code is written

using this language. It is everywhere, it is ubiquitous.

Bounded Context

A model exists within a context, and is protected by a boundary. We map

how different contexts interact, in order to avoid model corruption and

diffusion. This keeps our models focused on the task at hand.

Building Blocks

Domain-Driven Design defines a number of tactical design patterns, also

known as building blocks, that help us characterize the components of

the domain model. This let’s us clarify their responsibilities and restrain

the complexity of the code. Examples include Entity, Value Object,

Repository and Factory. 

Glossary

6

When doing Domain-Driven Design, developers and

domain experts create shared models by collaborating

using simple tools like whiteboards and flipcharts, and

by exploring the problem in source code that uses the

ubquitous domain language.

Well, an invoice

should always

specify the total …

I see - so what if

we update the

model like this?

7

Three Common Questions

about Domain-Driven Design

Question

Is the domain model the same thing as

our persistent classes?

Does DDD mean we have to model our

entire business in source code? That

seems hard.

We have a large and complicated

legacy code base, can we still use

Domain-Driven Design?

Answer

It is more than that. The domain model

is a tool for solving problems, a

reflection of our understanding of the

domain. The model is represented in

the source code and does all the hard

work in the application. Some or all of

it might be persisted using various

frameworks, but that's not the main

focus, or even a requirement.

Luckily, you don’t have to do that. A

domain model is created to help us

solve specifically chosen problems in

the domain. It does not contain things

not needed to solve those problems.

In fact, trying to create one shared

model for an entire business is a DDD

anti-pattern.

In messy legacy systems we cannot

always expect to get a grasp of a

clean domain model. However,

strategic design work can still be

done. We use strategic design to

visualize and understand the system at

a higher level of abstraction.

8

Citerus AB

Barnhusgatan 16

111 23 Stockholm

SWEDEN

+46 (0)8-562 95 300

info@citerus.se

www.citerus.se/ddd

Developing people and software