This is my personal favourite on DDD. I have only read this one. More suggestions below.
What Is Domain Driven Design or DDD?
Domain driven Design or DDD is mapping business domain concepts into software artifacts. Which means it is a kind of approach to develop software which is needed for complex business needs. We do it by deeply connecting the implementation to an growing model to the core business concepts.
To understand it better, you need to first understand what is domain. Domain is nothing but is a sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software. Aviation is a domain. Semiconductors are a domain.
To get to know this better. Let us take a simple example. You are about to design a building for the customer. For that we have given you a requirement list which comprises things like: we have provided you with a definite amount of land, the building must have 4 floors and each floor must have 5 rooms.
So the domain here in the above example can be “building”. But this domain name lacks some detailed information, and it could be difficult for you to even explain it to the clients or the contractors. So being specific, we can replace the domain name to “Residential Building”.
So, it’s much clearer for everybody to understand. And this analysis of yours lands you to another point called as “Ubiquitous Language”.
What is Ubiquitous Language?
The language which is common and can be understood by both the developer and the respective people is called the “Ubiquitous Language”. We base it on business terminology and not on technical terminology.
For instance, there is a statement which says that the ratio of length and breadth of the smaller bedrooms is 3:2. But if you consider the Ubiquitous Language, then the above statement is wrong.
Therefore, the correct statement is that the children’s bedroom’s length will be 15 feet and width will be 10 feet. The terms like “smaller room” and “ratio” could be very technical for the building owner, so refrain yourself from using it. So, this is one of the simplest examples for understanding Ubiquitous Language.
What are Bounded Contexts?
The context which contains its own domain, code and persistence mechanism. We consider it as a miniature application. A bounded context should always be logically consistent. And each bounded context should be independent of any other bounded context.
Understand this thing with a perfect example of an e-commerce system. Randomly you think about the work that comes under it can shop stuff and all. But if you think deeply, then you get to realize that there are more important things behind it, like inventory, delivery, accounts, etc.
If we again talk about the above mentioned example of “residential building”, then few more questions arise in the mind. Like, can you imagine a window without a room? Or does a window have any identity without the room it is living in?
Answering these two questions will let you explore three important concepts of Domain Driven Design (DDD)
- Entity.
- Value Object.
- Aggregates and Aggregate roots.
We discuss the above three points below with simple examples to let you understand DDD in a much better way.
What is Entity?
The important feature of the entity is that it has identity and is totally different within the system. The Example of entity in the “Residential Building” example can be:
- The bedroom in the building on each floor.
What is a Value Object?
Value object is just the opposite of an entity. So its key feature is that it is not unique and thus has no identity. We can represent value objects as attributes. So, two value objects can have identical attributes.
One more important feature of a Value object is that it is immutable and thus cannot be changed once created. So if you want to change it, then you are only left with creating the value object. We can easily do it as it does not have an identity.
Some common examples of Object value are:
- The windows are present in any of the rooms.
What is Aggregates and Aggregate Root?
Before defining it, just consider a minor example to understand this much better. For example:
- Room, Order and Question are our aggregate roots.
- Window, order note and question detail are our aggregates.
So from this example, we treat a cluster of associated objects as a unit regarding data changes. So aggregate is the cluster of all objects. And aggregate root is that root entity that has external access to all the objects.
Books On Domain Driven Design
For your assistance to let you understand DDD better, I am mentioning some of the popular as well as helpful books of which you can take full advantage.
- Patterns, Principles and Practices of Domain-Driven Design by Scott Millett
- Implementing Domain-Driven Design by Vaughn Vernon.
- Domain-Driven Design Using Naked Objects by Dan Haywood.
- Domain-Driven Design by Eric Evans. (I have only read this)
- Applying Domain Driven Design and Patterns by Jimmy Nilsson.
Conclusion
Domain Driven Design also encourages you for Test Driven Development (TDD), usage of patterns, and continuous refactoring. We consider it to be the most powerful concept that helps the modelers, architects, developers, and testers to work in the right direction.
The best way to make the most of it to practice DDD concepts as much as possible. Every time you design your object model, the more accuracy you will gain in all your design.
Photo by Kaboompics .com from Pexels.
Join to get sneak peek into what's happening
I write about books, experiences, product, UX, EdTech, early stage growth, validation – mostly tech. Subscribe if these topics interest you. Once every 15 days emailer. I promise – No spam. (I am known for it otherwise) 😉
