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.

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
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
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
61. COHESION Think about
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)
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)