2. Speaker
Eduards Sizovs
Software Architect at 4finance
- linkedin/in/eduardsi
- eduards.sizovs@gmail.com
3. Agenda
• What is DDD
• Principles
• Benefits
• Why people do not use DDD
• Building blocks
• How to start
4. What is DDD
• DDD – approach to developing software where
application’s domain model reflects real business
model and core domain is the primary project focus
domain.compareTo(technology) > 0
5. Close creative collaboration
• Team + Domain Experts works together
• Chaotic info is transformed into practical model
• Model is continuously distilled and refined
• It’s not just quizing for requirements
7. UL example (user story)
• Bad: When user logs in using valid data, his
active credits are displayed
• Good: When borrower logs in using valid
credentials, his open loans are displayed
8. Example
• User user = userFactory.newInstance();
• userService.register(user);
• Application application;
• Loan loan = loanService.takeCredit(application, user);
• if (loan != null) { ...
User user = userFactory.newUser();
user.register();
LoanApplication application;
Loan loan = user.applyForLoan(application);
if (application.rejected()) …
9. Natural refinement
If sophisticated can easily
That way we domain experts
do notweaknesses in the
find understand the model,
there is something wrong with
domain model
the model
10. Domain encapsulation
• Focus on specific business operation (e.g. Loans)
• Isolation from other domains (Loans from Credit
Bureau)
• Isolated from other layers (UI, integration)
• Loose coupling with external dependencies (anti-
corruption layer)
12. Domain’s richness
• Domain is a rich model of entities, relations, rules
and conditions, not just a data carrying entities
13. Benefits
• Ubiquitous Language in communication, requirements,
specification, domain model, tests
• Common model that the team can use to communicate about
business requirements
• The model is modular, extensible and easy to maintain
• Business model is encapsulated in one place
• Model is easy testable based on real business scenarios
• Final Code = Domain specification
14. If you do not follow DDD
• Likely you will have a fat service layer with anemic
domain model
• Domain rules and business logic are scattered in
many helpers and facades
• Harder to react to business requirement changes
• Communication is difficult
16. Anemic Domain Model
• Common architectural anti-pattern
• Violates basic OO principle – encapsulation
• “Service-driven DTOs”
17. Why people do not use DDD
• Complex component model with layering
enforcements (EJB 2.*)
• Easier to grasp with development with no prior
analysis (ad hoc development)
• Adapted to anemic domain model
• No access to domain experts
• No iterative development process
• Unwillingness to understand new domains
• Lack of good examples
18. Why people do not use DDD
• Clinging to technical things and frameworks
• DDD requires good OOA&D skills
• Thinking in terms of Computing
20. Entity
• An object defined primarily by its identity
• May have multiple representations
• Distinguished from another entity even both might
have the same attributes
• Example: Customer, Book, Vehicle
• Example: Two deposit transactions
21. Value Object
• An object having no identity and defined by its
attributes
• Describes state of entities
• Really powerful when built immutable
• Example: Money, Time
• Example: GPS program returns Route connecting
Boston and Rhode Island entities
22. Module (or package)
• Contains cohesive set of concepts
• Coevolves with a model
• Speaks UL
• When you place some classes together in a module,
you are telling next developer to think about them
together
23. Stadium seat example
• If visitors can sit wherever they find an empty seat
then seat is a...
• If visitors buy a ticket with a seat number on it, then
seat is a...
24. Aggregate
• A collection of objects that are bound together by a
root entity. The aggregrate root guarantees the
consistency of changes being made within the
aggregate by forbidding external objects from
holding references to its members
25. Repository
• A contract between application and data storage,
that speaks UL
• Pretends to be a collection of Aggregate Roots
• Repository is persistence ignorant
26. Example
• Payment Schedule comprises of Regular Installments
• Client pays-off Regular Installments
• Payment Schedule must be closed when all Regular
Installments get paid
• Payment Schedule gets processed according to client
payments
27. Factory
• Methods for creating domain objects should
delegate to a specialized Factory
• Helps when entity creation is complicated or reveals
its internal structure
• Decouples object creation from other layers
28. Service
• When an operation does not conceptually belong to
an Entity nor to a Value Object you can put it in a
service
• Services are still a natural part of a model
• Domain services should be distinguished from other
services (application, infrastructural)
29. Events
• Event captures a change to the model so different
model components can observe these changes and
react accordingly