2. Understanding the Domain.
Ubiquitous Language.
Contexts and Bounded Contexts.
Entities and Value Objects.
Aggregates and Aggregate Roots.
Persistence Ignorance.
Repository.
Domain Service.
3. “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
4. 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
5. 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
6. Objects who has Identity is Entity.
it is unique within the system.
e.g. Your bed room in the apartment.
7. 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.
8. 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.
9. 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 .
10. 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.
11. 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.