$30 off During Our Annual Pro Sale. View Details »

Domain Services and DDD Trilemma

Domain Services and DDD Trilemma

Zikriye Ürkmez

October 15, 2022
Tweet

More Decks by Zikriye Ürkmez

Other Decks in Technology

Transcript

  1. software development manager ABOUT ME introduce 10 + years backend

    developer 5 different company experiences manager of the great team always team member zİkrİye ürkmez linkedin.com/in/zikriye-urkmez-cengiz twitter.com/ZikriyeUrkmez github.com/zikriyeurkmezcengiz
  2. CONTENT table of domaın logıc what is domaın servıce decıdıng

    a domaın servıce DDD TRILEMMA final words
  3. DOMAIN LOGIC business logic, business rules, and domain knowledge ..

    logic that makes business-critical decisions enables a clear separation of concerns separate domain logic from other types of logic as it helps keep the overall code base simpler what is DOMAIN LOGIC APPLICATION LOGIC Resource: What is domain logic? · Enterprise Craftsmanship ** whether or not the code makes decisions that have a business meaning.
  4. remote procedure calls message oriented middleware system-level operations data persistence

    operations WHAT IS NOT? but first what Is domaın servıce? Vaughn Vernon, IMPLEMENTING DOMAIN-DRIVEN DESIGN Chapter 5 Implementing Domain-Driven Design : Vernon, Vaughn: Amazon.com.tr: Kitap
  5. don’t confuse a Domain Service with an Application Service what

    Is domaın servıce? "Application Service would normally be client of a Domain Service"
  6. finally When a significant process or transformation in the domain

    is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless. Eric Evans Domain-Driven Design Domain-Driven Design: Tackling Complexity in the Heart of Software : Evans, Eric: Amazon.com.tr: Kitap The Ubiquitous Language is a shared language developed by the team—a team composed of both domain experts and software developers.
  7. pure and complete model user domaın model orchestrator Use Case:

    changing the user email Domain rule: we can only assign to the user an email that belongs to the corporate domain of that user’s company
  8. pure but we lost completeness! Use Case: changing the user

    email Domain rule 1: We can only assign to the user an email that belongs to the corporate domain of that user’s company Domain rule 2: Before changing the user email, the system has to check whether the new email is already taken domain logic fragmentation alert!
  9. completeness but we lost purıty ! Use Case: changing the

    user email Domain rule 1: We can only assign to the user an email that belongs to the corporate domain of that user’s company Domain rule 2: Before changing the user email, the system has to check whether the new email is already taken a pure domain model is a model that doesn’t reach out to out-of-process dependencies
  10. always there ıs an thırd optıon! Use Case: changing the

    user email Domain rule 1: We can only assign to the user an email that belongs to the corporate domain of that user’s company Domain rule 2: Before changing the user email, the system has to check whether the new email is already taken Domain model is pure and it is also complete From performance standpoint it is not practical
  11. and the TRILEMMA Domain model purity vs. domain model completeness

    (DDD Trilemma) · Enterprise Craftsmanship
  12. make a choice If you can push all external reads

    and writes to the edges of a business operation without much damage to application performance, choose this option and keep domain pure and complete. Otherwise, choose domain model purity over completeness. Vladimir Khorikov Domain model purity vs. domain model completeness (DDD Trilemma) · Enterprise Craftsmanship
  13. makıng pure and complete models wıth Domaın servıces Selling mortgage

    loans To increase the efficiency of loan application processing automate application score calculation Domain rule 3: The loan monthly installment must not exceed 15% of the customer’s monthly income. Use Case: Domain rule 1: The customer age at the day of the last loan installment must not exceed 65 years. Domain rule 2: The property value must not exceed the requested loan amount. Applıcatıon servıce
  14. domaın model domaın servıce Scoring rules and evaluation implementation do

    not naturally belong to any entity or value object we have They are not part of the LoanApplication, nighter Loan, Customer or Property, therefore we created a separate class to represent the concept of rules and score calculation. Any changes here, like adding new rules, won’t require changes in the domain model. It is also an example of applying the single responsibility principle to our codebase. decıdıng domaın servıce
  15. avoid anemic model derived from the ubiquitous language always stateless

    not the responsibility of any existing domain object first class citizen of the domain model choose domain model purity over completeness (there is no doubting that it belongs within the Domain Model) conclusion ** A Domain Service seems like a neat solution to a problem, but you can very quickly find yourself in a situation where you have robbed the domain logic from the very objects that need it most. ** If you see the DRY principle is violated or the application service becomes too complex, you need to probably introduce a domain service.