Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

Getting modules right with Domain-driven Design

Getting modules right with Domain-driven Design

Domain-driven Design helps teams achieve a better alignment between the business and the technical architecture in order to design applications that have highly expressive and maintainable domain models. This talk aims at giving you an overview of Domain-driven Design and how the ideas behind it help you to create better modular applications.

We will talk about aspects from strategic Domain-driven Design such as Bounded Contexts and Subdomains, in addition to that the talk will explain the most important patterns from the tactical part of Domain-driven Design (Aggregate, Entity, Value Object). Finally you will learn about methods that help you in getting a better understanding about the domain you are working in.

Michael Plöd

May 27, 2022
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Get my DDD book cheaper Book Voucher: 7.99 instead of

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  2. Michael Plöd Fellow at INNOQ Follow me on Twitter under

    @bitboss Current consulting topics: • Domain-Driven Design • Team Topologies • Transformation from IT Delivery to digital product orgs Regular speaker at (inter-)national conferences and author of a book + various articles
  3. Domain Driven Design has great modularization concepts (Bounded Context, Aggregate)

    and an iterative approach for the identi ication of modules
  4. Bounded Context Bounded Context Bounded Context Module Granularity in DDD

    Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate
  5. „It is not the domain experts knowledge that goes into

    production, it is the assumption of the developers that goes into production” 11 Alberto Brandolini Inventor of EventStorming
  6. A B C „Gut, dass wir alle einer Meinung sind!“

    Inspiriert durch Jeff Patton & Luke Barren „good that we all share the same opinion“
  7. How the business names things TV Window Chair Trolley Painting

    Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
  8. Chaotic Exploration A Domain Event is the main concept of

    EventStorming. It is an event that is relevant for the domain experts and contextual for the domain that is being explored. A Domain Event is a verb at the past tense. The of icial EventStorming colour is orange.
  9. Enforcing the timeline In a second step we sort those

    events along a timeline. This will ignite quite a few discussions and may take some time.
  10. Pivotal Events & Swimlanes Mark those events that are very

    important. Those are your pivotal events. You may also highlight parallel streams of activity with swimlanes.
  11. Bounded Context A Bounded Context is a boundary for a

    model expressed in a consistent language tailored around a speci ic purpose
  12. A Bounded Context is a boundary for a model expressed

    in a consistent language tailored around a speci ic purpose Boundary Learning and mastering domain complexity Conducting experiments / Learning Delivering high value software
  13. A Bounded Context is a boundary for a model expressed

    in a consistent language tailored around a speci ic purpose Boundary for a model Business Rules Decisions Policies
  14. A Bounded Context is a boundary for a model expressed

    in a consistent language tailored around a speci ic purpose Language Terminology De initions Meaning
  15. Fruit Botanics Vegetable Cooking US Customs 25 Min Time Management

    A fruit or a vegetable? What is a tomato?
  16. Fruit Botanics Vegetable Cooking US Customs 25 Min Time Management

    Feedback Theater A fruit or a vegetable? What is a tomato?
  17. A Bounded Context is a boundary for a model expressed

    in a consistent language tailored around a speci ic purpose Purpose Language Rules Speci ic Model
  18. Botanics-US Customs-Cooking-Time management- Feedback Tomato It aims at speci ic

    models tied to a speci ic purpose The Bounded Context is not about the
  19. Some IT conference Registration of visitors Lunch planning Printing of

    badges Room planning Selling tickets Handling of payments
  20. YOU at some IT conference Registration of visitors Lunch planning

    Printing of badges Room planning Selling tickets Handling of payments
  21. You can group concerns Lunch planning Room planning Event Management

    Printing of badges Badges Registration of visitors Selling tickets Handling of payments Ticket Sales
  22. YOU at some IT conference Registration of visitors Lunch planning

    Printing of badges Room planning Selling tickets Handling of payments
  23. Bounded Context A Bounded Context is a boundary for a

    model expressed in a consistent language tailored around a speci ic purpose
  24. Look for terminology Application Form Scoring Rule Cluster Documents Real

    Estate Veri ication Income Veri ication Rejection Reference Properties Rejection Scoring Rule Cluster Credit Decision Template Credit Decision Hierarchy Contract Proposal Contract Welcome Letter Repayment Plan Decision
  25. 45 Domain Message Flow Modelling A Domain Message Flow Diagram

    is a simple visualization showing the low of messages (commands, events, queries) between actors, bounded contexts, and systems, for a single scenario. Source: https://github.com/ddd-crew/domain-message- low-modelling
  26. 48 Bounded Context Design Canvas The canvas guides you through

    the process of designing a bounded context by requiring you to consider and make choices about the key elements of its design, from naming to responsibilities, to its public interface and dependencies. Source: https://github.com/ddd-crew/bounded-context-canvas
  27. Bounded Context Bounded Context Bounded Context Let’s dig into the

    Bounded Contexts Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate
  28. Everything from here on is inside a Bounded Context We

    are now talking about more ine grained modules
  29. Aggregates (Internal) Building Blocks Entities Value Objects Factories Services Repositories

    TACTICAL DESIGN helps us with regards to evolvability of microservices
  30. Entities Entities represent the core business objects of a bounded

    context’s model Each Entity has a constant identity Each Entity has its own lifecycle Customer Credit Application Shipment
  31. Value Objects Value Objects derive their identity from their values

    Value Objects do not have their own lifecycle, they inherit it from Entities that are referencing them You should always consider value objects for your domain model Color Monetary Amount Customer
  32. <ValueObject> SelfDisclosure <ValueObject> Address <ValueObject> RedemptionDetail <Entity> Loan <Root Entity>

    LoanApplicationForm <Root Entity> <ValueObject> CustomerNumber <Root Entity> Customer Consider using Value Objects as indirect references between Aggregates
  33. Aggregate Domain Concepts Aggregates represent higher level business concepts. Behavior

    Try moving behavior to Value Objects in the Aggregates. The Entities should deal with lifecycle and identitiy. Invariants Aggregates allow us to implement and enforce rules and invariants (a incancial situation must have in- and outgoings)
  34. Hints Small Prefer small aggregates that usually only contain an

    Entity and some Value Objects. Consistency Boundaries Take a look which parts of your model must be updated in an atomically consistent manner One TX per Aggregate Aggregates should be updated in separate transactions which leads to eventual consistency Reference by Identity Do not implement direct references to other Root Entities. Prefer referencing to Identity Value Objects
  35. „the key to incremental architecture is to build on a

    framework that can accommodate change... that framework is the domain.... By modeling the domain, you can more easily handle changes to the domain“ Allen Holub https:/ /holub.com
  36. OOAD usually starts with nouns as class candidates, then goes

    to attributes and then verbs (methods) DDD starts with behavior (verbs) and looks then on structures Mind the difference between this approach and the classic object oriented analysis and design (OOAD)
  37. www.innoq.com Thanks! Michael Plöd Twitter: @bitboss LinkedIn: https://www.linkedin.com/in/michael-ploed/ Get my

    DDD book at a discount with: https:/ /leanpub.com/ddd-by-example/c/speakerdeck (or by scanning the QR code) Check out https:/ /socreatory.com for DDD trainings with me (onsite or online as well as in German or English)