Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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.

21a532a137b506128914478ac521fc8b?s=128

Michael Plöd

May 27, 2022
Tweet

More Decks by Michael Plöd

Other Decks in Programming

Transcript

  1. Getting Modules Right MICHAEL PLÖD FELLOW with Domain Driven Design

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

    (min) 9.99 http://leanpub.com/ddd-by-example/c/speakerdeck
  3. 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
  4. Separation of Concerns is the division of complex systems according

    to responsibility
  5. Modularity is a specialization of SoC and about information hiding

    loose coupling high cohesion
  6. Domain Driven Design has great modularization concepts (Bounded Context, Aggregate)

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

  8. Bounded Context Bounded Context Bounded Context Module Granularity in DDD

    Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate
  9. Bounded Context Bounded Context Bounded Context Let’s start with Bounded

    Contexts
  10. https://github.com/ddd-crew/ddd-starter-modelling-process

  11. https://github.com/ddd-crew/ddd-starter-modelling-process

  12. https://github.com/ddd-crew/ddd-starter-modelling-process

  13. https://github.com/ddd-crew/ddd-starter-modelling-process

  14. „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
  15. A B C „Gut, dass wir alle einer Meinung sind!“

    Inspiriert durch Jeff Patton & Luke Barren „good that we all share the same opinion“
  16. for doing Domain Driven Design Domain expert knowledge is essential

  17. we need direct collaboration

  18. None
  19. How the business names things TV Window Chair Trolley Painting

    Desk
  20. How the business names things TV Window Chair Trolley Painting

    Desk What we see in code TransparencyFactory RollableStuffContainer EntertainmentProviderSingleton DecoratorImpl RestProvider WorkEnablementDevice
  21. DOMAIN MODEL Domain Experts Developers Ubiquitous Language Conversations Code Drawings

    Documentation
  22. Event Storming is a direct collaboration workshop for various stakeholders

    of a piece of software
  23. 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.
  24. 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.
  25. 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.
  26. Quiz: which of these events are pivotal?

  27. Quiz: which of these events are pivotal?

  28. 23 https://github.com/ddd-crew/ddd-starter-modelling-process

  29. Text... Shape... Color... Size... There are many choices to group

    domain concepts 24 Output quantity
  30. Boundaries between Pivotal Events Heuristic: A pivotal event will probably

    sit on a boundary of a module
  31. Mind the swimlanes Heuristic: Swimlanes can help you in identifying

    further cohesion criteria
  32. Bounded Context A Bounded Context is a boundary for a

    model expressed in a consistent language tailored around a speci ic purpose
  33. 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
  34. 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
  35. 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
  36. A fruit or a vegetable? What is a tomato?

  37. A fruit or a vegetable? What is a tomato?

  38. Fruit Botanics A fruit or a vegetable? What is a

    tomato?
  39. Fruit Botanics Vegetable Cooking A fruit or a vegetable? What

    is a tomato?
  40. Fruit Botanics Vegetable Cooking US Customs A fruit or a

    vegetable? What is a tomato?
  41. Fruit Botanics Vegetable Cooking US Customs 25 Min Time Management

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

    Feedback Theater A fruit or a vegetable? What is a tomato?
  43. 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
  44. 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
  45. Some IT conference Registration of visitors Lunch planning Printing of

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

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

    Printing of badges Badges Registration of visitors Selling tickets Handling of payments Ticket Sales
  48. Don’t Repeat Yourself

  49. YOU at some IT conference Registration of visitors Lunch planning

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

    model expressed in a consistent language tailored around a speci ic purpose
  51. This has no purpose at all and the language is

    also not speci ic here
  52. Maybe those are interesting bounded context candidates? Event Management Badges

    Ticket Sales
  53. 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
  54. 44 https://github.com/ddd-crew/ddd-starter-modelling-process

  55. 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
  56. None
  57. 47 https://github.com/ddd-crew/ddd-starter-modelling-process

  58. 47 https://github.com/ddd-crew/ddd-starter-modelling-process

  59. 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
  60. None
  61. COHESION Think about

  62. None
  63. None
  64. None
  65. None
  66. Bounded Context Bounded Context Bounded Context Let’s dig into the

    Bounded Contexts
  67. Bounded Context Bounded Context Bounded Context Let’s dig into the

    Bounded Contexts Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate Aggregate
  68. 56 https://github.com/ddd-crew/ddd-starter-modelling-process

  69. Everything from here on is inside a Bounded Context We

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

    TACTICAL DESIGN helps us with regards to evolvability of microservices
  71. 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
  72. 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
  73. Entity Value Value

  74. Entity Value Value Using only Entities and Value Objects you

    will end up with big object graphs
  75. Entity Value Value Aggregates group Entities and Value Objects

  76. ROOT ROOT ROOT Value Value ROOT Each Aggregate has a

    Root Entity, aka Aggregate Root
  77. <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
  78. 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)
  79. 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
  80. Design Level EventStorming helps you to identify and design aggregates

  81. Design Level EventStorming

  82. Starting point

  83. Chaotic Exploration on business rules

  84. Which grouping of the rules is the right one?

  85. „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
  86. These groups are great candidates for aggregates!

  87. 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)
  88. None
  89. 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)