Microservices, Bounded Contexts, and Everything in Between

DDD eXchange 2018

Transcript

1. Microservices Bounded Contexts And Everything in Between
2. @vladikk vladikk.com
3. ”95% of the words are spent extolling the benefits of “modularity” and that little, if anything, is said about how to achieve it” Glenford J. Myers Composite / Structured Design, 1974
4. “MICROSERVICES FTW!!!!!!!!1” Me @ Internovus
5. “MICROSERVICES FTW!!!!!!!!1” Me @ Internovus
6. ”95% of the words are spent extolling the benefits of “modularity” and that little, if anything, is said about how to achieve it” Glenford J. Myers Composite / Structured Design, 1974
9. Decomposition Strategies Bounded Contexts, Business Domains, 
 Business En66es Design Heuristics Microservices Wrap-up Example Business Domain 1 2 3 4 5
10. Your Product Marketing
 Strategy Creatives Campaigns Sales
 Agents Optimization Profits
11. Decomposi9on Strategies Bounded Contexts Subdomains Business Entities and Processes
12. Bounded Contexts
14. Domain Expert Software Developer
15. Business Domain Expert Software Developer ??? !!! Ubiquitous Language
16. Campaigns Sales
 Agents Your Product Marketing
 Strategy Creatives Optimization Profits
17. Sales Agent Campaign Manager ??? !!! LEAD?
18. Conflicting models Different contexts Dividing the language/model Bounded Context
19. Marke9ng Sales Lead Lead Funnel Campaign Placement Landing Page Agency Insertion Order Message Campaign Proposition Desk Conversion Contact CDR Bounded Contexts
20. Marke9ng Service Sales Service Decomposi9on Strategy #1: Bounded Contexts
21. Marke9ng Sales Commissions Desks Sales
 Optimization CRM Telephony Creative Catalog Contracts Billing Campaign Management Identity & Access Ads Optimization Identity & Access
22. Subdomains
23. Business Domain: Customer Acquisi6on Bounded Context: Marke6ng Bounded Context: Sales Subdomain: Crea6ve Catalog Subdomain: Campaigns Mngmt Subdomain: Ads Op6miza6on Subdomain: Contracts Mngmt Subdomain: CRM Subdomain: Sales Op6miza6on Subdomain: Commissions Subdomain: Desks Mngmt
24. Decomposi9on Strategy #2: Subdomains Campaign Management Service Content Catalog Service Desks Management Service CRM Service Users Service Billing Service
25. Business En99es and Processes
26. Marke9ng Creative Catalog Contracts Billing Campaign Management Identity & Access Optimization Campaign Management Campaign Placement Funnel Banner Landing Page Website Zone Asset Publisher Target Market
27. Decomposi9on Strategy #3: En99es Website Asset Target Market Broker Distribu6on Customer
28. Decomposi9on Strategies Bounded Contexts Subdomains Business Entities and Processes
29. SHOW ME THE MICROSERVICES!
30. Bounded Contexts == Microservices ?
31. Sales Agent Campaign Manager ??? !!! LEAD?
32. Marke9ng Sales Lead Lead Funnel Campaign Placement Landing Page Agency Insertion Order Message Campaign Proposition Desk Conversion Contact CDR
33. Marke9ng Sales Lead Lead Funnel Campaign Placement Landing Page Agency Insertion Order Message Campaign Proposition Desk Conversion Contact CDR
34. Marke9ng Sales Commissions Desks Optimization CRM Telephony Creative Catalog Contracts Billing Campaign Management Identity & Access Optimization Identity & Access Lead Lead
35. Marke9ng Sales Commissions Desks Optimization CRM Telephony Creative Catalog Contracts Billing Campaign Management Identity & Access Optimization Identity & Access Lead Lead
36. Marke9ng Creative Catalog Campaign Management Optimization Lead Sales Commissions Optimization CRM Lead Desks Telephony Support Contracts Billing Identity & Access
38. Bounded Context Consistency boundary of the language / model Define the biggest valid monoliths Required decomposition boundary
39. Bounded Contexts == Microservices? No
40. Campaign Management Campaign Placement Funnel Banner Landing Page Website Zone Asset Publisher Target Market Campaign Website Placement Funnel Marke9ng Creative Catalog Contracts Billing Campaign Management Identity & Access Optimization Bounded Contexts? No Subdomains? En99es?
41. Microservices
42. Service “A service is a unit of functionality exposed to the world” - Juval Lowy “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface” - OASIS
43. “A service is a unit of functionality exposed to the world” - Juval Lowy “A mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface” - OASIS Service
44. Service Interface “Any mechanism for getting data in or out of the service” - Randy Shoup
45. Service Interface Asynchronous: • Producing events • Consuming events Synchronous: • Request / Réponse • Bulk ETL
46. Service Interface “Any mechanism for getting data in or out of the service” - Randy Shoup
47. Service Interface
48. Services ➜ Microservice
49. A microservice is a service with a micro interface
50. Microservice = Microinterface Reducing coupling between services Limits reasons for change Easier to understand Better fault isolation More autonomy between services
51. Microservice & Databases Microservices should own its database No external access Access through Microservice’s API only Database = infinite interface!
52. But!
53. 1 Method = Perfect Microservice !!??
58. STAFF ONLY STAFF ONLY
59. The threshold upon which a system can be decomposed into microservices is defined by the use cases of the system that the microservices are a part of.
60. Monolith Microservices Distributed
 Monolith Cost of Change
61. Big Ball Of Mud Bounded Contexts Microservices Distributed Big Ball Of Mud Avg. Service Size
62. Campaign Management Campaign Placement Funnel Banner Landing Page Website Zone Asset Publisher Target Market Campaign Website Placement Funnel Subdomains? En99es?
64. ”Global complexity … the complexity of the overall structure of a program or system. I.e., the degree of association or interdependence among the major pieces of a program” Glenford J. Myers Composite / Structured Design, 1974
65. ”Global complexity … the complexity of the overall structure of a program or system. I.e., the degree of association or interdependence among the major pieces of a program” Glenford J. Myers Composite / Structured Design, 1974
66. When you design a system…, then if the features can be broken into … loosely bound groups of rela>vely closely bound features, then that division is a good thing to be made a part of the design. This is just good engineering. Tim Berners-Lee Principles of design, 1998
67. Services + Good Engineering = Microservices
68. Its is not only necessary to make sure your own system is designed to be made of modular parts. It is also necessary to realize that your own system … should always be designed to be a part of another larger system. Tim Berners-Lee Principles of design, 1998
69. A major part of this paper will be concerned with the ques>on of how good modularity can be achieved, that is, how modules can be chosen so as to minimize the connec5ons between them. Barbara Liskov A design methodology for reliable soIware systems, 1972
70. A microservice is a service with a micro interface. The threshold upon which a system can be decomposed into microservices is defined by the use cases of the system that the microservices are a part of.
71. A microservice is a service with a micro interface. The threshold upon which the system can be decomposed is defined by the use cases of the system that the microservices are a part of. …how to evaluate?
72. Design Heuris9cs
73. Heuris9c #1: Decompose to Bounded Contexts Do not implement conflicting models in the same service. Always decompose to Bounded Contexts.
74. Heuris9c #2: Don’t ”First Law of Distributed Object Design: 
 “Don’t distribute your objects” Mar9n Fowler
75. Heuris9c #2: Don’t Benefits Addi6onal
 Complexity
76. Heuris9c #2: Don’t Benefits Addi6onal Complexity
77. Core Supporting Generic
78. Generic Subdomains No competitive advantage Everybody is implementing in the same way Complex business logic
79. Marke9ng Sales Commissions Desks Optimization CRM Telephony Creative Catalog Contracts Billing Campaign Management Identity & Access Optimization Identity & Access Generic
80. Heuris9c #3: Buy/Adopt Generic Subdomains Your System 3rd party product
81. Heuris9c #3: Buy/Adopt Generic Subdomains Your System 3rd party product An6-Corrup6on Layer
82. Core Subdomains Inventing something new Optimizing existing paractices Competitive advantage Complex business logic Change often
83. Core Subdomains Inventing something new Optimizing existing paractices Competitive advantage Complex business logic Change often
84. Heuris9c #4: Core Subdomains - Don’t Rush Adhere to subdomain’s boundaries. Decompose further only when you acquire domain knowledge.
85. Suppor9ng Subdomains No competitive advantage Support the Core Subdomains Can’t be bought / adopted Simple business logic
86. Marke9ng Sales Commissions Desks Sales Optimization CRM Telephony Creative Catalog Contracts Billing Campaign Management Identity & Access Ad Optimization Identity & Access Generic Core Supporting
87. Suppor9ng Subdomains No competitive advantage Support the Core Subdomains Can’t be bought / adopted Simple business logic
88. Heuris9c #5: Suppor9ng Subdomains - Early Can be decomposed beyond the subdomain’s boundaries.
89. Core Supporting Generic
90. Heuris9c #6: Evaluate Consistency Requirements Method A Method B
91. Heuris9c #6: Evaluate Consistency Requirements Concurrency control? - Same service Method A Method B 
 Service A
92. Heuris9c #6: Evaluate Consistency Requirements Read last write? - Two services, synchronous communication 
 Service A Method A 
 Service B Method B Sync call
93. Heuris9c #6: Evaluate Consistency Requirements Eventual consistency? - Two services, asynchronous communication 
 Service A Method A 
 Service B Method B Asynchronous Communication
94. Heuris9c #6: Evaluate Consistency Requirements Concurrency control? - Same service Read last write? - Two services, sync communication Eventual consistency? - Two services, async communication
95. 
 Service A Method A 
 Service B Method B Asynchronous Communication
96. Heuris9c #7: Public / Private Events Service Event Type 1 Event Type 2 Event Type 3 Event Type 4 Event Type 5 Event Type 6 Event Type 1000 … Private event types (Implementation details) }Public event types (Public interface) }
97. Service EmailChanged PhoneNumberChanged AddressChanged ContactDetailsChanged Private event types (Implementation details) } Public event type (Public interface) } Heuris9c #7: Public / Private Events
98. Heuris9c #7: Public / Private Events Events?
99. Heuris9c #7: Public / Private Events Events? Domain Events State Change
 Events
100. Heuris9c #7: Public / Private Events Events? Domain Events State Change
 Events Private Public
101. Heuris9c #8: Make Events Explicit Eliminate ambiguity
102. Heuris9c #8: Make Events Explicit Service AgentAssignedToLead
103. Heuris9c #8: Make Events Explicit Service AgentAssignedToLead AgentAssignedToLead AgentAssignedToLead
104. Heuris9c #8: Make Events Explicit Service AgentAssignedToLead AgentUnassigned AgentAssignedToLead
105. Heuris9c #9: Evaluate Reasons for Change Service A Service B
106. Same reasons for change? Same rate of change? Can be decoupled? Should be the same service? Heuris9c #9: Evaluate Reasons for Change
107. Heuris9c #10: Evaluate Services’ “Doors”
108. Heuris9c #10: Evaluate Services’ “Doors” STAFF ONLY STAFF ONLY
109. Summary
110. 1. A service is a unit of func6onality exposed to the world through its public interface. 2. A microservice is a service with micro interface 3. The “micro-interface” is rela6ve to the use cases of the system that the service is a part of
111. Heuris6c #1: Always decompose to Bounded Contexts Heuris6c #2: Don’t go further, unless you have to Heuris6c #3: Buy/adopt generic subdomains Heuris6c #4: Core Subdomains - don’t rush Heuris6c #5: Suppor6ng Subdomains can be decomposed early
112. Heuris6c #6: Evaluate Consistency Requirements Heuris6c #7: Private / Public Events Heuris6c #8: Explicitly Define Events Heuris6c #9: Evaluate Reasons for Change Heuris6c #10: Evaluate Services’ “Doors”
113. Big Ball Of Mud Bounded Contexts Microservices Distributed Big Ball Of Mud Avg. Service Size
114. Bibliography 1. A Design Methodology for Reliable Soeware Systems, Barbara Liskov 2. Composite/Structured Design, Glenford Myers 3. Domain-Driven Design: Tackling Complexity in the Heart of Soeware, Eric Evans 4. Emerging Boundaries, Mathias Veraes 5. Implemen6ng Domain-Driven Design, Vaughn Vernon 6. Enterprise Integra6on Paherns, Gregory Hohpe, at al 7. Long Sad Story of Microservices, Greg Young 8. Managing Data in Microservices, Randy Shoup 9. Microservices, At Last Some Boundaries, Eric Evans 10. On the Criteria to be Used in Decomposing Systems Into Modules, David Parnas 11. Paherns of Enterprise Applica6on Architecture, Mar6n Fowler, at al 12. Principles of Design, Tim Berners-Lee 13. Programming WCF Services, Juval Lowy 14. What Every Programmer Should Know About Object Oriented Design, Melir Page-Jones
115. THANK YOU! @vladikk vladikk.com
116. QUESTIONS? @vladikk vladikk.com
117. THANK YOU! @vladikk vladikk.com