Domain Driven Design (DDD)

Domain Driven Design (DDD) is not an improved technology or specific method. Domain Driven Design (DDD) is an approach that tries to bring solutions to the basic problems frequently experienced in the development of complex software systems and in ensuring the continuity of our applications after the implementation of these opposing projects. To understand Domain Driven Design (DDD), some basic concepts need to be mastered. With these concepts, we can enter the Domain Driven Design (DDD).

Ubiquitous Language

It is one of the cornerstones of Domain Driven Design (DDD). We need to be able to produce the desired output of the software developers and to ensure the continuity of this output to be able to speak the same language as the Domain Expert. Afterwards, we have to transfer this experience to the methods and classes that we use while developing our applications by giving the names of the concepts used by experts. Every service we will use in our project must have a response in the domain. Thus, everyone involved in the project can speak this common language and understand each other.

Entitiy & Value Object

Objects with a unique identity are called Entity, while those that do not have a unique identity are called a Value Object. Entities correspond to a concept in our domain. Domain Driven Design (DDD) is strictly dependent on object oriented programming. It suggests that we should not only write our business logic to services, but also entities should have it. Briefly, we have to create our classes in a structure that does not correspond to a table in our database. In other words, we must create entities by adding logic.

Aggregate Root (AR)

The combination of entities associated with each other to achieve a business rule or flow is defined as Aggregate. Entities, which are just an object on their own, form Aggregate by accessing a transactional integrity within the work sharing. Within this structure, an executive entity is selected to ensure the coordination of other entities. This selection points to the Aggregate Root in the aggregate. In Domain Driven Design (DDD), ARs do not directly or indirectly communicate with Entity in another AR and do not include their references. ARs should only communicate with each other.

Bounded Context

A recommended approach to use in Domain Driven Design (DDD) complex systems. The complex may contain sub domains within a domain. It should also include Domain Driven Design (DDD). Example of e-commerce site; · Order management · Customer management · Stock management · Delivery management · Payment System management · Product management · User management may contain many sub domains. As these sub domains are grouped, Bounded Context refers to structures in which the group of individuals most logically associated with each other in terms of the rules of the Aggregate Roots are grouped together and the responsibilities of this group are clearly defined.