-Tatyaso Patil

Understanding the Domain. Ubiquitous Language. Contexts and Bounded Contexts. Entities and Value Objects. Aggregates and Aggregate Roots. Persistence Ignorance. Repository. Domain Service.

“Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.”

Traditional Approach-bottom to up approach.

DDD-Top to Bottom approach

developers and the business should share a common language.

It is set in business terminology, not technical terminology.

e.g. Constructing Building vs. Constructing Residential building

It is a miniature application, containing it’s own Domain, own code and persistence mechanisms.

Bounded Context should be independent of any other Bounded Context.

Dividing a large application among different bounded contexts properly will allow you to make your application more modular

bounded contexts of residential:◦ Electricity supply◦ Car parking◦ Apartment 

Objects who has Identity is Entity. it is unique within the system. e.g. Your bed room in the apartment.

it has no Identity. e.g.

An order note can only exist if an order is placed. Windows in the rooms. A question detail can only be there if a question is asked.

An Aggregate is a group of associated objects which are considered as one unit with regard to data changes.

Aggregates draw a boundary around one or more Entities Aggregate root is an Entity, and it is the only object

accessible from outside. E.g. Room, Order and Question are our aggregate roots.  window, order note and question detail are our aggregates.

In domain driven design your objective is to create a model of the domain  

identify what are the items (objects) you need to accomplish the desired functionalities of your application.

You do not need to know how and where the data of your domain will persist .

repository will be responsible to store your data and to retrieve your data 

Repository Mediates between the domain and data mapping .

Rpository doesn’t talk in terms of “data”, it talks in terms of Aggregate Roots.

Services act as interfaces which provide operations.

Domain Services are usually built on top of domain Entities and Values providing required functionality directly related to those objects.

If Entities and Value Objects are the “things” in your domain, the services are a way of dealing with actions, operations and activities. 

domain services as façade layer of the business logics and operations of your domain.