About Petri Kainulainen

Petri is passionate about software development and continuous improvement. He is specialized in software development with the Spring Framework and is the author of Spring Data book.

Domain-Driven Design Revisited

Recently I read a book titled Domain-Driven Design by Eric Evans. This wasn’t the first time I read this book but this time I realized that I had been totally wrong about domain-driven design.

I thought that the domain model consists of entities and value objects. In fact, I was obsessed with moving the domain logic to entities and value objects. I wanted to do it so bad that I ignored a crucial warning.

My code was cleaner than it used to be but I always felt that I was missing something.

 
When was I reading Domain-Driven Design for the second time, I realized what I had missed.

The Building Blocks of a Domain Model

My mistake was that I was so obsessed with entities and value objects that I forgot the other building blocks of a domain model.

Domain-Driven Design describes the domain model as follows:

A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert’s head; it is a rigorously organized and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence.

However, reading this definition did not change my mind. In fact, when I read it I was feeling proud of myself because it seemed to verify that I was doing the right thing.

Then I started reading the second part of the book which talked about the building blocks of a model-driven design and the house of cards, which I had so carefully crafted, fell apart.

This part argues that the model-driven design has the following building blocks:

  • Entities are objects which are defined by their identity. In other words, if an object has an identity which stays unchanged through its entire lifecycle, this object should be modelled as an entity.
  • Value objects describe a property of a thing, and they don’t have their own identity or lifecycle. Often their lifecycle is bound to the lifecycle of an entity.
  • Services contains operations that don’t belong to entities or value objects. If adding an operation to an entity or value object doesn’t feel natural to you, the odds are that you should add this operation to a service.
  • Modules (Packages) are used to reduce cognitive overload. They give a developer the possibility to either investigate the internals of a single module without paying attention to other modules or investigate the relationships between modules without paying any attention to the implementation details.
  • Aggregates are groups of objects which are treated as a single unit. Each aggregate has a root object which is used to access the other objects of the aggregate. Each aggregate has also a boundary which defines what objects belong to the aggregate in question.
  • Factories are used to encapsulate the creation logic of an object or an aggregate. Factories are useful if the creation logic is complicated or reveals too much about the internal structure of the created object.
  • Repositories are used to fetch entities from the used data storage and save the information of entities to it.

After I had finished the book, I had no other choice than to admit that I had no idea what domain-driven design really is.

The good news is that I still have got plenty of time to learn.

What Did I Learn?

The biggest thing which I learned by reading the Domain-Driven Design for the second time should be pretty obvious now but I did pick up a few other lessons as well:

  • I understood the difference between the application services and the domain services. Application services coordinates the tasks and delegates work to domain objects. Domain services implement operations which don’t belong to entities or value objects. In other words, application services don’t contain business logic and domain services contain it.
  • I understood that the domain model doesn’t have to be an exact copy of the reality. I can simply pick the parts of the reality which are useful to me and forget the rest. This seems obvious at first but it is also very easy to forget this.

My next step is to learn more about domain-driven design. To be more specific, I want to figure out how I can use these building blocks in my daily work. That is why I already ordered Implementing Domain-Driven Design by Vaughn Vernon.

What is your next step?

Reference: Domain-Driven Design Revisited from our JCG partner Petri Kainulainen at the Petri Kainulainen blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Domain-Driven Design Revisited"

  1. Thanks for the very simple explanation of the building blocks. Am still confused about what logic goes in to domain and services. Am trying to create a POC implementing DDD, CQRS and Event store. I follow your blog as well. Once again, Thanks so far.

Leave a Reply


− 3 = three



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close