This document discusses the key concepts of domain-driven design (DDD), including ubiquitous language, bounded contexts, entities, value objects, aggregates, aggregate roots, persistence ignorance, repositories, and domain services. It explains that DDD takes a top-down approach, focusing on the domain model first before technical implementation. It emphasizes establishing a shared language between developers and business stakeholders and dividing large applications into independent bounded contexts to improve modularity.

1. -Tatyaso Patil

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.