Search:

Domain Driven Design

Domain Driven Design

It is an approach that tries to solve the problems that are frequently experienced when developing complex software systems. In order to understand DDD, some basic concepts need to be mastered. We can achieve the DDD by these concepts.

Ubiquitous Language: All the stakeholders of the software product should be able to speak the same language, which is naming for the business concepts should be the same, in order to deliver the desired output and ensure the quality of the output.

Bounded Contexts: Complex structures should contain subdomains, and these subdomains should be grouped among themselves. These structures are called Bounded Context.

For example :

- Order Domain

- Stock Domain

- Product Domain

Entity & Value Object: DDD recommends that business logic should be built on business entities not on services.

Aggregate Root (AR): There should be aggregate roots where the entities associated with each other working together.

Repository: There should be repository levels which only responsible for the persistence of domain entities. Repository layers should not contain any other business logic.

Layered Architecture: Regardless of whether or not microservice architecture is used, there should be layers of the product architecture. Here is a well-known 4-tier architecture:

- Domain Layer

- Application Layer

- Presentation Layer

- Infrastructure Layer

 

Orhan Burak Bozan

Software Consultant at kloia

Want to work with us?

A wonderful serenity has taken possession of my entire soul, like these sweet mornings of spring which I enjoy with my whole heart. I am alone, and feel the charm of existence in this spot.

Contact us