4. WHAT IS DDD?
•It is a way of thinking and set of rules for
developing software with complicated
domains.
•Model driven software design approach to
tackle complexity of software project.
•Collection of principles and patterns that
help craft elegant systems.
5. DEFINITIONS
•Domain - A sphere of knowledge or
activity.
•Model – Abstracts domain in simple way.
Distilled form of knowledge, assumptions,
rules and choices.
10. PRINCIPLES
•Speaks Ubiquitous Language
•Explore models with collaboration with
domain practitioners and software
practitioners.
•Focus on core domain
•Model and implementation are bound,
developers are responsible for the model.
12. UBIQUITOUS LANGUAGE
•Language structured around the domain.
•The language will be used to discuss and
will also be represented in code
•Change in ubiquitous language <=>
Change in code & model
13.
14. EXPRESSING MODEL
•Model can be expressed through UML
diagrams, etc
•Design document is not the model
•Model ultimately is represented in code.
15.
16. BREAK DOWN COMPLEX
MODEL
•Bounded Context – An operational
definition where model is well defined and
applicable.
•Subdomain – Part of the domain, based on
a particular conceptual decomposition of
the domain.
20. ENTITIES
•Object’s identities remains same
•Distinguishable from other object having
same attr
•Attributes of entity are mutable
•Entities should have behavior
•NO PERSISTENCE BEHAVIOR
21. VALUE OBJECTS
•Things that does not have uniqueness
•Equal to other value object if value is
same
•Value object are immutable
•Example: Money, Address, DTO
22. AGGREGATES
•Cluster of entity of value object. Treated
as single unit
•Each aggregate has a root entity known as
Aggregate Root
•External object may only reference to the
root
•Internal aggregate can only be change
26. DOMAIN SERVICES
•Domain Services is business logic, not
part of entity or value object
•Services manipulate multiple entity or
value object
•Services are stateless
•Parameter and result are domain object
29. MODULES
•Break up complex domain
•High cohesion within module, loose
coupling between module
•Part of ubiquitous language
•Helps with decoupling
•Extensible
31. NOT SAME
•Subdomain - decomposition of domain
•Module – decomposition of model &
associated software
•Aggregate – Decomposition of run time
data
•Service – Decomposition of functionality
•Bounded context – Linguistic barrier
32. NOW WHAT ??
•Because we put bounded context to the
application, data query and aggregation
becomes harder
33. CQRS
•Needs to make changes to data and to
query data is different.
•To make changes to data we need
complex long validation
34.
35.
36. LITTLE BIT OF ONION
RING•Out of topic
•Often pair together with DDD
37.
38.
39. Good system enables average
people to achieve great things.
Bad system makes great people do
normal things.