Domain Driven Design Ruby Ways

1. DDD DISTILLED
JONATHAN WYLLIEM

2. DDD IN A NUTSHELL
JONATHAN WYLLIEM

3. WHAT IS DOMAIN ??

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.

6. THREE LAYER CAKE

7. 5 LAYER CAKE

8. PEOPLE TRY EATING WHOLE CAKE

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.

11. PRINCIPLES
•Publish event when changes to aggregate
happens

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

14. EXPRESSING MODEL
•Model can be expressed through UML
diagrams, etc
•Design document is not the model
•Model ultimately is represented in code.

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.

18. EXPRESS MODEL IN
SOFTWARE
•Entities
•Value Objects
•Aggregates
•Services
•Associations

19. EXPRESS MODEL IN
SOFTWARE
•Factories
•Repositories
•Modules
•Context Mapping

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

23. AGGREGATES
•SalesInvoice
- TransactionLine 1
- TransactionLine 2
- TransactionLine 3
- TransactionLine 4

24. ASSOCIATIONS
•Impose traversal direction
•Add a qualifier, reduce multiplicity
•Eliminate non essential associations
•Both a gift and a curse in Rails

25. SERVICES
•Application services: CSV Exporter
•Domain services: Debit / credit account
balance
•Infrastructure services: Send email
services

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

27. FACTORIES
•Model responsible creating other object
•Create and manage complex domain
object (aggregate root)

28. REPOSITORIES
•Encapsulate data persistence
•Clean seperation of domain and data store
layer
•May encapsulate multiple fetch strategy,
caching, NoSQL, SQL
•One repository per aggregate

29. MODULES
•Break up complex domain
•High cohesion within module, loose
coupling between module
•Part of ubiquitous language
•Helps with decoupling
•Extensible

30. CONTEXT MAPPING
•Mapping context point between bounded
context
•Shared kernel
•Customer/Supplier
•Conformist
•ACL

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

36. LITTLE BIT OF ONION
RING•Out of topic
•Often pair together with DDD

39. Good system enables average
people to achieve great things.
Bad system makes great people do
normal things.