Understanding. Domain-Driven Design

Transcription

1 Understanding Domain-Driven Design 1

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

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

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

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

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

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

8 Citerus AB Barnhusgatan Stockholm SWEDEN Developing people and software +46 (0)