Domain Driven Design

https://www.geeksforgeeks.org/domain-driven-design-ddd/

What is Domain?

The word domain used in context of software development refers to business. domain logic == business logic.

When we are developing software our focus should not be primarily on technology, rather it should be primarily on business (domain).

Component

Entity

The instance of entity has a global identity and keeps same identify throughout lifespan. Identity never changes. It generally persisted as a row in DB and consists of value objects.

Can we say one entity is one business object?

Value Object

Value Object has no identify. User is an entity and address is a value object.

Services

Service is a stateless class. Services is neither related to an entity nor vlaue objects.

Aggregates

An aggregates is a collection of entities and values which come under a single transaction boundary (??) Aggregates has a root entity called aggregate roots. The root entity governs lifetimes of other entities in aggregates.

User and Order are root entity. when they got deleted no use for other entities.

Factories and Repositories

We should always create repository per aggregate root but not for all entities. For example we have UserRepo but not AddressRepo.

Rules (Micro Service Patterns, Chapter 5)

Rule # 1 Reference only the aggregate root

Rule # 2 Inter Aggregate reference must use Primary Keys

Rule # 3 One transaction creates or update one aggregate. Like we can put User and Order in one DB transaction but we should not do that. This is really good for microservice architecture. Different aggregates may use different storage like NoSQL for User and MySQL for Order.

The Z company doesn’t flow the Rule # 3, everything is in one transaction which makes it very hard to decompose.

The aggregate boundaries are not set in stones.