This document provides an overview of domain-driven design (DDD). Some key points: DDD focuses on modeling the core domain and business logic of an application rather than technical implementation details. It advocates building a domain model that represents the problem domain and expressing that model in code. Some DDD concepts discussed include entities, value objects, aggregates, repositories, domain services, bounded contexts, and context mapping. The document explains how to identify and define these concepts to structure an application around the business domain. Following DDD principles like defining a ubiquitous language, building models driven by the domain, separating bounded contexts, and mapping dependencies can help produce applications that are more maintainable, scalable, and focused on

1. Domain Driven Design
Satish Mittal
VP Engineering
Practo

2. Motivation
Typical application development:
Requirements from business
Task breakdown
Jump to implementation
DB schema - tables and columns
Fast, we are a Startup!

3. Problems
1. Your project has the same functionality implemented in the same way or
different in different places?
2. You have more than one object for the same item?
3. You have objects that have properties that are not actually attributes of that
object?
4. You have no or very poor relationship among related items?
5. Looking at your objects it is not possible to understand what actually the
whole application is all about?

4. Problems
Bottom-up vs Top-down approach
Here-and-now vs big-picture
Do I understand the domain of the application?

5. Solution
Domain Driven Design (DDD)
Coined by Eric Evans
Wikipedia: 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.
Idea: Focus more on complexities intrinsic to core business domain

6. Domain
Wikipedia: A sphere of knowledge, influence, or activity. The subject area to
which the user applies a program is the domain of the software
Examples:
E-commerce
Professional network
Advertisement
Healthcare
...

7. What is a model?
It’s not just diagrams (UML, ER): views of model
Model is the set of concepts that we have chosen to implement in our software
Business differentiator

8. Pattern: Model-driven design
First build an of domain model that actually represents the problem domain
Then express that in code at all times
Change in domain <-> Change in code

9. Ubiquitous Language
All stakeholders should speak the same language
Product-developers
Developers-developers
The language must be business language, and not technical details

10. Language: Entity
A concept that has a unique identity within system
Two entities can only be same if their identity is identical
Typically persisted, mutable, status change
Examples:
Friend in Facebook
Item in shopping cart: SKU
News Article: URL

11. Language: Value Object
Represents a set of attributes
e.g. doors in a room, items in an order, profile details
Typically it has no unique identity of its own
It should be immutable
In some cases, Value Object might become an entity (when unique identity is
needed to invoke some action)
Example: last N SearchCriteria

12. Language: Value Object
E.g. money: int, double field in code?
How about various currencies: INR/USD?
Recommendation: Define unique class
Money m1 = new Money("GBP", 10);
Money m2 = new Money("GBP", 20);
Money m3 = m1.add(m2);
Typically immutable
Adding m1 to m2 doesn’t alter m1; returns m3

13. Language: Value Object
E.g. SocialSecurityNumber
E.g. MobilePhoneNumber
E.g. PatientRegistrationNumber
Perform common validations within each class: range check, syntax, format
Refactor duplicate implementations out of applications

14. Language: Module
Package or library or namespace
Collection of entities and Value Objects related to a context
Focus on having as much reusable modules amongst applications across
company

15. Language: Aggregate Roots
Entity relationship types: association, aggregation or composition
An aggregate root (AR) is an entity that composes other entities (as well as its
own Value Object) by composition.
Example:
Consult Question (AR) contains multiple Answers. However any Answer can’t exist without
Question
Aggregated entities are referenced only by the root (may be transitively), and
may not be referenced by any objects outside the aggregate.
Some entities are aggregate roots themselves (single node tree)

16. Language: Aggregate Roots
Identifying AR allows us to define the logical atomic unit of work
critical section of a transaction
AR is responsible for ensuring that all its child entities are always in consistent
state across operations
Example:
Order (AR) contains OrderItems; all OrderItems must be unique
Referential Integrity across ARs:
Appointment for a slot must be given only if Doctor is available that day

17. Language: Repository
Domain must be agnostic of persistence (MySQL, ES, Redis, FS..)
Repository is an abstraction over persistence layer
Returns collections of aggregate roots (typically meeting some criteria)
Repository is a domain level concept - represented via Interface
Actual implementations belong to Infrastructure layer
Dependency Injection

18. Domain Service: Represents core business actions, operations on Domain
Entities; manages business rules
Example: Appointment booking, medicine order
Application Service: Handles cross-cutting concerns like transactions, security
etc.
Infrastructure Service: Underlying tech implementation layer
Example: MySQL, SMS communicator, push notification
Language: Service Types

19. Language: Service Types
Layered architecture

20. Spectrum of granularity
Value Object < entity < aggregate < module < bounded context

21. Language: Bounded Context
BC: The functional boundary within which domain model make sense
Recommendation: Divide large application among multiple BCs
More modular
Separation of different concerns
Helps manage and enhance application in an efficient way
Each BC operates in a semi-autonomous fashion
Each BC owned by separate team: domain expert
Avoid BBOM (Big Ball of Mud): unstructured, duct-tape, sphagetti code

22. Bounded Context: Relationships
published language: the interacting BCs agree on a common language (e.g.
domain schema) by which they can interact with each other;
open host service: a BC specifies a protocol (e.g. RPC/RESTful web service)
by which any other BC can use its services;
shared kernel: two BCs use a common kernel of code (e.g. a library)

23. Bounded Context: Relationships
customer/supplier: one BC uses the services of another and is a stakeholder
(customer) of that other BC. As such it can influence the services provided by
that BC;
conformist: one BC uses the services of another but is not a stakeholder to that
other BC. As such it uses "as-is" (conforms to) the protocols or APIs provided
by that BC;
anti-corruption layer: one BC uses the services of another and is not a
stakeholder, but aims to minimize impact from changes in the BC it depends
on by introducing a set of adapters – an anti-corruption layer.

25. Context Map
DDD recommends to draw Context Map to identify which BC do you depend
upon, and which BC depend upon you
Dependency graph amongst systems, with edges that capture the co-operation
level
Helps understand the inter-dependencies better
Helps streamline upstream model changes

26. Thanks!