Microservices without DDD is risky business!
How relevant is domain-driven design (DDD) 13 years after Eric Evans' well-known blue book? The book and the community it grew out of was to a large extent defined by how large enterprises built their IT systems at the start of this century, dominated by the two large and all-encompassing platforms J2EE and .NET, often constructed in a very planned and controlled way. How on earth could this then be relevant in a world dominated by agility, microservices, and a plethora of technologies and platforms? Actually, central DDD concepts like bounded context, core domain, ubiquitous language, distillation, and aggregates fits even better in such a dynamic world than the large monoliths we struggled with back then. This rich toolbox contains techniques that helps us getting more intimate with the business, better understanding their visions and needs; principles helping us designing better and more sustainable solutions that are closely linked with the domain; and pattens for constructing autonomous components in an agile fashion. Fits like a glove! Presentation held at JavaZone 2016.
Microservices without DDD is risky business!
- 1. Making IT your winning asset
- 2. Trond Hjorteland Partner at scienta.no @trondhjort
- 3. Microservices without DDD is risky business!
- 4. @trondhjort
- 5. Imposter syndrome Source: David Whittaker @rundavidrun What I think others know What I know What I know What others know @trondhjort
- 6. @trondhjort
- 8. ¡°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
- 9. Source: D.L. Parnas, Communications of the ACM, 1972
- 11. Source: ¡°From Capabilities to Services¡¡±, Ulrich Homann & Jon Tobey 2006@trondhjort
- 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
- 18. @trondhjort
- 19. "DDD, for me, is a mindset, a journey, a way of ¡®learning¡¯ more about a business domain and its problem, not a destination or an artefact in some code base.¡± @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
- 21. Strategic patterns Source: Domain-Driven Design Reference@trondhjort
- 22. Source: Patterns, Principles and Practices of Domain-Driven Design@trondhjort
- 23. Source: Ulrich Kalex, The Open Group@trondhjort
- 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@trondhjort
- 27. @trondhjort
- 28. Tactical patterns Source: Domain-Driven Design Reference@trondhjort
- 30. Subdomain ? Service (BC) ? Aggregate Subscription Portfolio Owner Portfolio management ? Taxonomy Portfolio Subscription A Subscription B Subscription C ? @trondhjort
- 31. Delivery approaches Top-down Bottom-up Architecture principles Inverse Conway Manoeuvre @trondhjort
- 33. @trondhjort