Domain Driven Design (DDD)

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