Domain-Driven Design by Eduards Sizovs

1. Introduction to
Domain-Driven Design

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

6. Common (Ubiquitous) language
• Model is based on Ubiquitous Language
(UL)
Model
Team Customer

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)

11. Technical simplicity
• No heavyweight framework dependencies
• POJOlicious design

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

15. From PEAA

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

19. Building blocks

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

30. Specification & Function
• Entity.satisfies(Specification)
• Entity.apply(Function)
• Specification.satisfiedBy(Entity)
• Function.applyTo(Entity)

31. Strategic design
• Abstract Core Domain & Generic Subdomains
• Bounded Context & Context Map
• Anti-Corruption Layer

32. More reading
• DDD community at domaindrivendesign.org
• Books by:
– Martin Fowler
– Kent Beck
– Alan Kay
– Ward Cunningham

33. Thank you!