Domain Driven Design (DDD) is a software development approach that focuses on modeling a complex domain into code. The document discusses key DDD concepts like entities, value objects, aggregates, repositories, bounded contexts, and validation. It provides examples of how these concepts are implemented in code and outlines challenges and situations where DDD may not be appropriate, such as for non-complex domains without behavior/logic or where the data model maps directly to a relational database schema.

1. Domain Driven Design
BY AMIT MUKHERJEE
TECHNICAL ARCHITECT - TECH MAHINDRA
AMIT.MUKHERJEE@TECHMAHINDRA.COM

2. Agenda
Why
Building blocks
◦ Repositories, entities, specifications etc.
Putting it to practice
◦ Dependency injection
◦ Persistence
◦ Validation
◦ Architecture
Challenges
When not to use DDD

3. Software is complicated

4. Traditional Architecture

5. Onion Architecture
-Domain model != view model
(The M in MVC)
-Instead of depending
downwards, dependencies goes
inwards

6. public bool CanBook(Cargo cargo, Voyage voyage)
{
if (!overbookingPolicy.IsAllowed(cargo, voyage))
return false;
...
}
public bool CanBook(Cargo cargo, Voyage voyage)
{
double maxBooking = voyage.Capacity * 1.1;
if (voyage.BookedCargoSize + cargo.Size > maxBooking)
return false;
...
}

7. Domain Model

8. The domain model requirements and
phases

9. Solution Structure

10. Essentials of DDD - Entities
-Like a person, you can change everything
about them: name, address, sex
-But over their whole lifetime they’re still the
same person
-Same with object, entities are the same
object for the duration of their lifetime
-Implemented with an identifier or ID

11. Essentials of DDD – Value Objects
Value Objects
-Value types on the other hand
-Are identified by their value
-E.g. color, addresses, shopping lists
- Define by logic and data
- Any two value objects with same data are
the same
- They are immutable

12. Essentials of DDD – Aggregates
Value Objects
-Cluster of objects
-Consistency boundary
-Simplifies things massively
-Master object called aggregate root

13. Essentials of DDD – Aggregate Root
Value Objects
-Cannot hold reference to anything except the root
-Can’t access any entity except from the root
-Consistency boundary
-Save the whole thing
-Cascades
-Versioning
-Locking – coarse grain lock

14. Essentials of DDD – Repository
Value Objects
-Common pattern
-When you need something
-Where you put things when your application isn’t
using them
- Abstracts away persistence
- One repository is specific to one type of
aggregate root
- It contains collection of instance of aggregate
- And provide operations of loading and saving
aggregate instance

15. Essentials of DDD – Bounded Context
Value Objects
-Different definitions in different contexts
-E.g. different departments may reuse
language differently
Data Model applies or lives inside Bounded
Context
In an enterprise with many domain, many
Bounded Context exist together
Bounded Context refers to different aspect of
the domain

16. Essentials of DDD – Dependency Injection
Value Objects
-All about interfaces
-Decouple our code
-Depend on the model, not the
implementation
-Users of INotificationService have no idea
-Instead of calling out
-Inversion of control
public class LeaveService
{
private readonly INotificationService notifications;
public LeaveService(INotificationService notifications)
{
this.notifications = notifications;
}
public void TakeLeave(Employee employee, DateTime start, DateTime end)
{
this.notifications.Notify(employee, "Leave approved.");
}
}

17. Essentials of DDD – Validation
Is the first name filled in?
Is the e-mail address format valid?
Is the first name less than 255 characters long?
Is the chosen username available?
Is the password strong enough?
Is the requested book available, or already out
on loan?
Is the customer eligible for this policy?
public class PersonRepository : IPersonRepository
{
public void Save(Person customer)
{
if (!customer.IsValid())
throw new Exception(...)
}
}
Validating only before it writes to the DB
- self-validating entities (doesn’t work for
different contexts)

18. When DDD isn’t appropriate
 -DDD is for dealing with complex domains
 -If you don’t have a complex domain
 -If you have no behavior or logic
 -If your ’model’ maps perfectly to a relational DB schema
 -Clues that you don’t need DDD
 -If you don’t have access to a domain expert