Domain Driven Design (part 1)

We all have heard of Domain Driven Design and we all (including myself) are struggling to use it. Let's try to understand few things together.

Domain Driven Design is first coined by Eric Evans in his book which is a concept to structure projects using the business domain.

Domain is the King.

While we can arrange our structure in varies ways, there is a common factor in every project, "business domain". No matter, project domain is the reason why the project exists. It is clear that domain is the most valuable thing.

In his book, Eric Evans describes how we can build our projects centering the domain.

Fair enough, for small projects this may be over engineering.

In his book, he mainly focuses on the domain layer in our system.

Domain - Domain is the real world problem we are going to solve in our application. Domain refers to the specific subject that the project is being developed for. The subject area to which the user applies a program is the domain of the software.
Domain Model - Domain model is our organised and structured knowledge of the problem.
Domain Driven Design - Domain driven design is architecting our project according to the domain.
Bounded Context - A doamin can be divided into multiple sub-domain. Each sub-domain is known as bounded context.

Building blocks

Bigger projects are harder to implement and maintain. Domain driven design gives us a way to structure domain layer by breaking into meaningful responsibilities.

Entities - entities are the things with identity. It maintains independent behaviour through it's life cycle. It will be unique within the domain. Passenger in taxi hailing domain is an entity.
Value objects - value objects do not have identity. However it represents part of the domain. For an example Address can be a value object that can be used by Passenger.
Services - in some cases, there will be no clear place to put operations. Domain services can be used those capabilities. Beware that these are domain services, not application or infrastructure services.
Aggregate Roots - an object which coordinates domain entities is called an aggregate root.
Events - events represent that something has happened in the domain.

Life Cycle Management

Life cycles of entities, values objects, services, aggregate roots can be managed by factories, repositories.

Factories - Factories provide necessary encapsulation to create entities, etc. We can use builders to minimize the complexity.
Repositories - To get or save the reference of an entity, repositories are used.

Ubiquitous language

This is the language everyone use to talk about the domain. Business experts, developers all use the same terms, verbal, writing or in the code itself same verbs, nouns will be used.

Manju