Skip to content

Latest commit

 

History

History
162 lines (119 loc) · 10.6 KB

README.md

File metadata and controls

162 lines (119 loc) · 10.6 KB
Raw

Domain Driven Desing (DDD) for developers

[TOC]

Introduction

There is a lot of information about DDD, but I can not find a short information what is the difference from Object-Oriented Analysis and Design (OOAD) and what changes developers could expect. So I try to extract and collect only small piece from big mountain where is software developers quickly understood the difference from most popular way of software development.

When DDD might be useful

There is no big point in using DDD if you have a small project or don't have a big problem in the current project. There are advantages and disadvantages to every design approach. We are trying to discover a few of them. The same things are seen in different ways depending on who is looking at them.
When a domain expert sees the room: image
Pic 1. Business names. (© Michael Plöd)

When a developer sees the same space: image
Pic 2. Naming in Software Code. (© Michael Plöd)
Can you see? Both people cannot work well together, they use different language for the same objects. Would it not be better if we spoke a common language?

The next example. Do you remember a similar structure in your project?
image
Pic 3. Common object. (© Michael Plöd) image
Pic 4. Division according to business areas. (© Michael Plöd)

Which objects would you like?

Two ways of thinking

Let us compare how we might think:

1. Our application is a collection of objects. Every object has attributes and methods - operations. Objects and data flow are our main guides.
Do you remember class inheritance and how every object can run? image
Pic 5. Class inheritance. (© libretexts.org) image
Pic 6. Class definition and implementation. (© aigents.co) image
Pic 7. OOP example. (© www.iameans.top)
image
Pic 8. OOP Layers. (© www.iameans.top)

2. Our application follow our buisness rules. A person start an action, we check some rules and finish the action.

image
Pic 9. DDD Layers 2003.(© Eric Evans)

Can you see the difference between this and the first way (Pic.8 vs Pic. 10)? image
Pic 10. Onion Architecture different view.(© Amichai Mantinband)

Most knowledgeable picture of domain-driven design architecture: image
Pic 11. Onion Architecture.(© Constantin Gustov)
So DDD does not require thinking about objects and data.

DDD vocabulary

DDD is not so easy to learn, there are a lot of new things that you need to know. I want to save your time and copy some definitions from the book5. image
Pic 12. Pattern Language Overview.(© Eric Evans)

  • Domain. A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. image © Michael Plöd

  • Model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.

  • Ubiquitous language A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.

  • Context The setting in which a word or statement appears that determines its meaning. Statements about a model can only be understood in a context.

  • Bounded context A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

  • Entities Many objects represent a thread of continuity and identity, going through a lifecycle, though their attributes may change. An object must be distinguished from other objects even though they might have the same attributes. Mistaken identity can lead to data corruption.

  • Value Objects Some objects describe or compute some characteristic of a thing. Many objects have no conceptual identity. When you care only about the attributes and logic of an element of the model, classify it as a value object. Treat the value object as immutable.

  • Domain Events Something happened that domain experts care about. A domain event is a full‐fledged part of the domain model, a representation of something that happened in the domain. Domain events are ordinarily immutable, as they are a record of something in the past. A domain event often has a separate timestamp indicating when the event was entered into the system and the identity of the person who entered it.

  • Services When a significant process or transformation in the domain is not a natural responsibility of an entity or value object, add an operation to the model as a standalone interface declared as a service. Define a service contract, a set of assertions about interactions with the service.

  • Modules Choose modules that tell the story of the system and contain a cohesive set of concepts. Give the modules names that become part of the ubiquitous language. Modules are part of the model and their names should reflect insight into the domain.
    image © Michael Plöd

  • Aggregates Cluster the entities and value objects into aggregates and define boundaries around each. Choose one entity to be the root of each aggregate, and allow external objects to hold references to the root only (references to internal members passed out for use within a single operation only). Define properties and invariants for the aggregate as a whole and give enforcement responsibility to the root or some designated framework mechanism.
    image © Thomas Ploch

  • Repositories Query access to aggregates expressed in the ubiquitous language. For each type of aggregate that needs global access, create a service that can provide the illusion of an in-memory collection of all objects of that aggregate’s root type. Set up access through a wellknown global interface. Provide methods to add and remove objects, which will encapsulate the actual insertion or removal of data in the data store.

How to model business processes

Event storming is the most popular process modelling. The idea is to bring together software developers and domain experts and let them learn from each other. The result is based on repetitive actions taken from the real world. image Pic 13. Introducing EventStorming.(© Alberto Brandolini) image Pic 14. Design Level EventStorming (© Michael Plöd) Here is an example of a possible result: image Pic 15. Event Storming by Judith birmoser.(© Judith Birmoser)

Note: Inside the ellipses is a bounded context

Application example

For better understanding I have found and improved a C# application. You can find description here

Learn more

I don't want to tell you - these are the best links. These are just some links to get you started.

Books

Note: Reading order is important - 1, 2, 3 (green, red, blue)/(overview, easy to understand, academic explanation)

  1. Vaughn Vernon Domain-Driven Design Distilled (about 160 pages)
    image

  2. Vaughn Vernon Implementing Domain-Driven Design (about 700 pages)
    image

  3. Eric Evanc Domain-Driven Design (about 450 pages)
    image

  4. Alberto Brandolini Introducing EventStorming
    image

  5. Eric Evans DDD Reference Free PDF.

Videos

Websites