Introduction to DDD

1,657 views

Published on

Domain-Driven Design by Eduards Sizovs

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,657
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
24
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • adadada
  • Introduction to DDD

    1. 1. Introduction toDomain-Driven Design
    2. 2. Speaker Eduards SizovsSoftware Architect at 4finance - linkedin/in/eduardsi - eduards.sizovs@gmail.com
    3. 3. Agenda• What is DDD• Principles• Benefits• Why people do not use DDD• Building blocks• How to start
    4. 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. 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. 6. Common (Ubiquitous) language• Model is based on Ubiquitous Language (UL) Model Team Customer
    7. 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. 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. 9. Natural refinementIf 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. 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. 11. Technical simplicity• No heavyweight framework dependencies• POJOlicious design
    12. 12. Domain’s richness• Domain is a rich model of entities, relations, rules and conditions, not just a data carrying entities
    13. 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. 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. 15. From PEAA
    16. 16. Anemic Domain Model• Common architectural anti-pattern• Violates basic OO principle – encapsulation• “Service-driven DTOs”
    17. 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. 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. 19. Building blocks
    20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. Events• Event captures a change to the model so different model components can observe these changes and react accordingly
    30. 30. Specification & Function• Entity.satisfies(Specification)• Entity.apply(Function)• Specification.satisfiedBy(Entity)• Function.applyTo(Entity)
    31. 31. Strategic design• Abstract Core Domain & Generic Subdomains• Bounded Context & Context Map• Anti-Corruption Layer
    32. 32. More reading• DDD community at domaindrivendesign.org• Books by: – Martin Fowler – Kent Beck – Alan Kay – Ward Cunningham
    33. 33. Thank you!

    ×