Scribd
Upload
112 views

Understanding DDD

Do you like Domain-Driven Design, but find it hard to explain it so others understand what's so good about it? In this small guide, you'll find a few arguments and explanations that might help you. Also available in print at www.citerus.se/understanding-ddd

Uploaded by

Citerus
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
112 views

Understanding DDD

Do you like Domain-Driven Design, but find it hard to explain it so others understand what's so good about it? In this small guide, you'll find a few arguments and explanations that might help you. Also available in print at www.citerus.se/understanding-ddd

Uploaded by

Citerus
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 8

Understanding

Domain-Driven Design

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 behaviors 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.

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 its shared by more than one coworker.

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.
4

Glossary
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 set of abstractions that describes selected aspects of a domain. We use models 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 lets us clarify their responsibilities and restrain the complexity of the code. Examples include Entity, Value Object, Repository and Factory.
5

Well, an invoice should always specify the total

I see - so what if we update the model like this?

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.

Three Common Questions about Domain-Driven Design


Question
Is the domain model the same thing as our persistent classes?

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 dont 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.

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?

Citerus AB Barnhusgatan 16 111 23 Stockholm SWEDEN 8

Developing people and software

+46 (0)8-562 95 300 [email protected] www.citerus.se/ddd

You might also like