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.

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

9. Source: @mathiasverraes

10. Customer
Account
Subscription
@trondhjort

11. Source: http://bill-poole.blogspot.com, 2008@trondhjort

12. Source: “What Comes After Microservices?”, Matt Ranney at YOW! 2016

13. Source:(http://geek/and/poke.com/(
Source: http://geek-and-poke.com/@trondhjort

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

29. Aggregate Subscription
Portfolio
Owner
Portfolio
Subscription
A
customerId
Subscription
B
Subscription
C
Subscription
B
?@trondhjort

30. Subdomain ⊇ Service (BC) ⊇ Aggregate
Subscription
Portfolio
Owner
Portfolio
management
⊇
Taxonomy
Portfolio
Subscription A Subscription B Subscription C
⊇
@trondhjort

31. @trondhjort

33. Photo: Tori Hogan

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