What is Domain Driven Design (DDD) ?
I was writing about what is microservice architecture and its advantages/disadvantages. Today I am gonna write about “What is Domain Driven Design ?” and how we can use it with our software development process. Advantages/Disadvantages I wanna explain what is advantages/disadvantages before writing how we will implement it. You can efficiently break down large projects and manage your teams successfully with DDD. Thanks to this approach, we can write clean and testable code. In addition, our code becomes easily interchangeable and developers can adapt faster because of we divide software into pieces. Dezavantajları If the project is really huge, this approach benefits. When we use it in smaller projects, the effort what we spend and the result of product may not pleasure us. Developers should understand the requirements of the domain and stay in constant contact with the Domain Expert. In addition, it takes a lot of time to prepare a domain model at the beginning. We need people who are experts in the domain to create a good model design.
Domain Driven Design:
DDD is one of the best design to create your microservices. To use this method, we must understand our problem well and divide it into pieces correctly. Mosf of use heard about “Domain”. Domain defines the scope of the application that we will create. As an example, E-commerce projects are in the E-commerce domain, banking applications are in the banking domain.Martin Fowler says that DDD is a software development approach that focuses on programming with a rich understanding of the processes and rules of a domain. An Example:
Our first step for DDD is to define the business domain. In other words, what domain can our application be placed under and what can be the subdomains of the application ? I want to consider the e-commerce project again as it is a stream that many of us know.
Bounded Context:
The diagram you see above is a graph with the needs of a simple e-commerce site, in fact, a defined version of our problem. Bound Context is the solution area of the designated domain/sub-domains and determines the boundaries of these domains.For this example, we can create a single bound context or multiple bound contexts for subdomains.
When creating a domain model with DDD,there are concepts such as Aggregate/Entity-Objects/Vale Objects, Services, Repositories, Events.
Aggregate/Entity-Objects :
Aggregate bound is the most basic element of our contexts. As an example, Order is an aggregate and OrderLineItems is an entity object. Entity objects cannot exist without root aggregate, but they have an identity value.An aggregate contains multiple collections of entity objects. DDD aggregate map should not be confused with collection classes such as list. The phrase "Aggregate" is used in different contexts such as uml but does not mean the same as we use here.
Value Objects:
Value objects are not an identifier, so there are no identity values.Order aggregate contains List where OrderLineItem is an entity, but Order can also contains a class called OrderDetail.Here we should note that Orderdetail does not have an identity value such as Id. This and DTOs(Data transfer object), which we can define similarly, appear as a value object. Value objects can differ by combining multiple field values.
Service:
Services are basically the expression of the business rule definition as object. It helps aggregates to run Business logic according to the limits of bound contexts. In other words, there are functions in it. if there is no entity relationship with another object, we can call them services.
Repository:
Except that we are used to Git, At DDD Repository is structures that hold the states of all aggregate/entity Operations contained in the Bound Context. We do CRUD operations through Repository. For example, bringing orders belonging to the customer or updating the order status, etc. Repository is used directly in database operations.
Events:
Let's divide each subdomain into subdomains of our e-commerce application and think of each subdomain as a bound context. In this case, we need to communicate between bound contexts. As an example, when an order is created, the customer's bound context needs to be aware of this process, so we can trigger an event called OrderCreated.As a result, we can say that we communicate between our microservices through events.
Although we cannot say that Domain Driven Design is only used in microservices architecture, it provides a suitable structure for us to separate and maintain these services.
References: https://martinfowler.com/bliki/DomainDrivenDesign.html https://airbrake.io/blog/software-design/domain-driven-design
