Microservices without DDD is risky business! REDUX
Just about everyone is doing microservices these days, at least that's what they're claiming. Microservices is the new black! But, how well are they really doing? When breaking things up there is a risk of ending up in the same rut as SOA did a decade ago, in effect creating distributed monoliths. So, is it at all possible for anyone to reach the promised land consisting of autonomous, cohesive, and loosely coupled services? My claim is that it is doable, but not without some up-front modelling under the guidance of Domain-driven Design concepts like "bounded context", "core domain", "ubiquitous language" and ¡°aggregates¡±. Distilling the domain, drilling deep into the core business concepts, and breaking it up into isolated and protected contexts will take you a long way. Add some business capability modelling and service-orientation into the mix, and you are halfway there. Use it as a map to guide you on the journey towards an orderly and robust distributed system, built by adding one MVP at the time in a low-risk agile manner. This is a redux of the 2016 talk with the same title.
Microservices without DDD is risky business! REDUX
- 1. Microservices without DDD is risky business! R E D U X
- 2. @trondhjort Source: Strategic & Sociotechnical DDD Patterns, Nick Tune at ?Con London 2019
- 3. @trondhjort
- 4. Source: ¡°Testing in Production at Scale¡±, Amit Gud at SREcon
- 5. @trondhjort Large High coupling Low cohesion Small Low coupling High cohesion Monolith Microservices Modular monolith SOA 2.0
- 6. ¡°This _____ discusses modularisation as a mechanism for improving the flexibility and comprehensibility of a system while allowing the shortening of its development time.¡± @trondhjort -David Parnas, 1972 paper
- 7. Source: D.L. Parnas, Communications of the ACM, 1972@trondhjort
- 12. Source: ¡°What Comes After Microservices?¡±, Matt Ranney at YOW! 2016
- 14. @trondhjort Large High coupling Low cohesion Small Low coupling High cohesion Monolith Microservices Modular monolith SOA 2.0 Distributed monolith ?Services nServices
- 15. @trondhjort
- 16. Service-orientation Boundaries are explicit Services are autonomous Services share schema and contract, not class Service compatibility is based on policy s @trondhjort
- 17. Source: ¡°From Capabilities to Services¡¡±, Ulrich Homann & Jon Tobey 2006@trondhjort
- 20. Collaboration of software and domain experts Focus on the core domain Ubiquitous language in a bounded context The essence of DDD @trondhjort Source: Domain-Driven Design Reference, Evans
- 21. Strategic patterns Source: Domain-Driven Design Reference, Evans@trondhjort
- 22. Source: ¡°Patterns, Principles and Practices of Domain-Driven Design¡±, Tune & Millett@trondhjort
- 23. The Enterprise Source: Business Capability Management, Ulrich Kalex 2011@trondhjort Corporate Management Market Dev. Oversight Delivery Product Dev. Market Development Contact Man. Revenue Analysis Regional Market Man. Order and Contract Man. Market Analysis Support & Services Direct Marketing Channel Man. Sales Man.
- 24. Subdomains Customer Account Subscription Billing Customer Care Subscription Management Billing Account Customer Subscription Portfolio Owner Payer Sales Invoice Install base Products @trondhjort
- 25. ¡°All models are wrong but some are useful¡± -George Box Source: Robustness in Statistics, 1978@trondhjort
- 26. Source: Implementing Domain-Driven Design, Vaughn Vernon@trondhjort
- 27. @trondhjort
- 28. Tactical patterns @trondhjort Source: Domain-Driven Design Reference, Evans
- 30. Subdomain ? Service (BC) ? Aggregate Subscription Portfolio Owner Portfolio management ? Taxonomy Portfolio Subscription A Subscription B Subscription C ? @trondhjort
- 31. @trondhjort
- 34. Source: MicroservicePrerequisites, Martin Fowler 2014
- 35. Source: ¡°Accelerate¡±, N. Forsgren et al 2018
- 36. ¡°A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.¡± -John Gall
- 37. Making IT your winning asset trondhjort