DDD, necessary but insufficient: physical design principles for microservices

My #exploreDDD 2024 talk:

When we design software using DDD, we primarily focus on creating models scoped by bounded contexts that define ubiquitous languages. We also structure the models and the elements they contain to be loosely coupled and highly cohesive. However, while (logical) design techniques such as DDD domain modeling concepts, loose coupling and high cohesion are essential for creating good software, they are insufficient when designing a microservice architecture. In particular, we must also consider other more physical constraints including team size; team, process and transaction boundaries; and the cost of communication over a network.

In this talk, I describe a set of physical design principles for organizing subdomains into microservices. You will learn about both principles that encourage finer-grained decomposition into services as well as those that discourage decomposition. I describe how to apply those principles to design a microservice architecture.

Transcript

1. @crichardson DDD, necessary but insu ff i cient: physical design principles for microservices Chris Richardson Microservice architecture consultant and trainer Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns Founder of Eventuate.io @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2024. Chris Richardson Consulting, Inc. All rights reserved
2. @crichardson Essence of using the microservice architecture = Designing the service architecture (Not setting up Kubernetes)
3. @crichardson Use DDD: bounded contexts => services? Adrian Cockcroft: https://www.slideshare.net/adriancockcroft/dockercon-state-of-the-art-in- microservices
4. @crichardson Presentation goal DDD principles are insuf fi cient when designing a microservice architecture Physical design principles are also required
5. @crichardson About Chris http://adopt.microservices.io Late 80s 2006 2008 2009 2012-
6. @crichardson About Chris https://chrisrichardson.net/
7. @crichardson Agenda The microservice architecture: what is it and why? Designing a microservice architecture Dark energy forces: encouraging decomposition Dark matter forces: resisting decomposition
8. @crichardson Microservice architecture: two or more (executable/deployable) components Production Deployment pipeline Service Repo Deployment pipeline Service Repo Deployment pipeline Service Repo Independently deployable Loosely coupled Svc Svc Svc Some system operations span multiple services
9. @crichardson O VID -19 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ Accelerates delivery of complex applications Process: DevOps/Continuous Delivery & Deployment Organization: Network of small, loosely coupled, product teams IT must deliver software rapidly, frequently, reliably and sustainably Businesses must be nimble, agile and innovate faster S/W VUCA Microservice architecture Enables Enables
10. @crichardson Enables a great DevEx for complex applications DevEx Work environment than minimizes interruptions, meaningful work, … Minimize - simplify environment, automate, good documentation, … Fast feedback from colleagues, tools, deployment pipeline, production, users, … Feedback Flow Cognitive load https://queue.acm.org/detail.cfm?id=3595878 Great
11. @crichardson IF you have this DevEx… Large monolith • High cognitive load • Less autonomy • More meetings • Slow feedback Single classpath, Large code base, Slow deployment pipeline, … Simple (e.g. ACID txns) development BUT You
12. @crichardson …THEN adopt microservices to have this DevEx Service Small part of a large application Service … Service … Service … collaborators A P I • Less cognitive load • More autonomy incl. technical • Less meetings • Faster feedback You A P I A P I A P I Service … Service … clients
13. @crichardson Agenda The microservice architecture: what is it and why? Designing a microservice architecture Dark energy forces: encouraging decomposition Dark matter forces: resisting decomposition
14. @crichardson How to de fi ne a Microservice architecture? Microservice architecture The Process API Responsibilities Collaborations Functional requirements As a consumer I want to place an Order So that I can …. As a Restaurant I want to accept an Order So that I can …. Event storming Wireframe/UI mockups Delivery Address Available Restaurants Restaurant Menu System quality attributes • SLA: Reliability/Latency • Scalability • …
15. @crichardson Apply DDD (obviously)! External behavior Business logic/ capability Act on aggregates
16. @crichardson How to organize DDD subdomains/BCs into services? Microservice architecture ? API Responsibilities Collaborations Subdomain /BC Subdomain /BC Subdomain /BC Subdomain /BC
17. @crichardson Simplest option: Subdomain/ BC = service…
18. @crichardson Subdomain/BC = service: the good Focus: logical design principles - naming, design-time coupling, cohesion Bounded contexts are: Mostly loosely design-time coupled Mostly cohesive Possibly loosely runtime coupled via messaging
19. Subdomain/BC = service: the bad MICROservices != little services Risk of creating excessively fi ne- grained, overly complex architecture Ignores physical design issues: overhead/complexity of distribution, eventual consistency, runtime coupling, … https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html
20. @crichardson Monolithic architecture is not an anti-pattern + A service should exist to solve a problem
21. @crichardson Better approach: Service = collection of Subdomains/BCs Order Service «Subdomain» Order Management «Aggregate» Order «Subdomain» Coupon Management «Aggregate» Coupon Sometimes: A single service is suf fi cient, i.e. a monolith
22. @crichardson Grouping subdomains into components: together or separate? ≪subdomain≫ Customer Management ≪aggregate≫ Customer ≪subdomain≫ Order Management ≪aggregate≫ Order Attraction Repulsion Generated by system operations Simple components Team autonomy Fast deployment pipeline … Dark energy: an anti- gravity that’s accelerating the expansion of the universe Dark matter: an invisible matter that has a gravitational effect on stars and galaxies. https://www.nasa.gov/feature/goddard/2020/new-hubble-data-explains-missing-dark-matter Simple interactions Prefer ACID or BASE Minimize runtime coupling … https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
23. @crichardson Dark energy and dark matter forces https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for … SystemOperation() Generates Forces that act on subdomains and determine grouping into services
24. @crichardson Designing an architecture = making trade-offs Con fl icting forces Therefore Some services/ operations will have an optimal design Others will be suboptimal but good enough Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple, efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for Fine-grained services Monolith
25. @crichardson Agenda The microservice architecture: what is it and why? Designing a microservice architecture Dark energy forces: encouraging decomposition Dark matter forces: resisting decomposition
26. @crichardson Dark energy repulsive forces 㱺 subdomains in different services https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsive dark energy forces Characteristics: • Resource requirements • Regulations, e.g. SaMD/PCI • Business criticality/tier • Security, e.g. PII, … • DDD core/supporting/generic • ...
27. @crichardson A service exists to resolve a dark energy force
28. @crichardson Simpler components/services Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B More complex service: Dependencies, and runtime behavior Simpler services: easier to understand, develop, test, … versus
29. @crichardson Team autonomy = service per team Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B Coordination required Build, test and deploy independently vs. Team A Team B Team A Team B
30. @crichardson Fast deployment pipeline: short lead time/fast feedback @mipsytipsy https://speakerdeck.com/charity/cd?slide=17 Service Subdomain Subdomain Service Subdomain Shorter lead time Simpler build Longer lead time More complex build* * Accelerate build/test: • Merge queue • Incremental testing through DIP and ISP • Parallelization/clustered builds • Selective test execution
31. @crichardson Support multiple technology stacks: per-subdomain Service Python Service Java Service JVM Subdomain A Subdomain A Subdomain B Subdomain B Single technology stack Separate technology stacks Right tool for the job versus
32. @crichardson Support multiple technology stacks: incremental upgrades Need to periodically upgrade each component in order to keep its technology stack current A component must be upgraded completely - not partially Task size ∝ complexity(component) The business often resists large tasks that don’t implement features Therefore Separate subdomains to reduce service upgrade effort
33. @crichardson Separate subdomains by characteristics Subdomain characteristic Issue Resource requirements Cost-effective, scalability Regulations, e.g. SaMD/ PCI DevOps vs. Slower regulated process Business criticality/tier Maximize availability Security, e.g. PII, … Improve security DDD core/supporting/ generic Focus on being competitive
34. @crichardson Cost effective scaling Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B versus CPU MEM GPU Scale together • Wasteful • Costly CPU MEM GPU Scale separately • Ef fi cient • Cheaper Load Load Load Load EC2: p4d.24xlarge EC2: p4d.24xlarge EC2: m5.24xlarge 8x cost!
35. @crichardson Example: Segregate by business criticality Service Service Service Payment Processing Payment Processing Merchant management Merchant management Shared infrastructure Risk of interference Separate infrastructure Isolated vs. chargeCard() 2.9% + 30c/ request Revenue loss and penalties chargeCard() Critical Important
36. @crichardson Segregate regulated software Service Service Service SaMD Subdomain SaMD Subdomain Other Subdomain Other Subdomain ISO 13485 ISO/IEC 62304 ISO 13485 ISO/IEC 62304 DevOps Slower Faster
37. @crichardson But your context determines relevance of dark energy forces to your application Force: reason to use microservices What determine relevance to your application Team autonomy ∝Number of teams Fast deployment pipeline Build time ∝ size/complexity of app Build frequency ∝ rate of Git pushes Multiple technology stacks Need multiple technologies? Segregate by characteristics Business criticality Have high availability subdomains? Regulations Regulated subdomains? …
38. @crichardson Service per subdomain/BC often solves non-existent problems and creates new problems …
39. @crichardson Agenda The microservice architecture: what is it and why? Designing a microservice architecture Dark energy forces: encouraging decomposition Dark matter forces: resisting decomposition
40. @crichardson Dark matter attractive forces 㱺 subdomains in same service https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Attractive dark matter forces SystemOperation() Generates
41. @crichardson Simple interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Complex distributed operation Simple local operation: easier to understand, troubleshoot, … vs.
42. @crichardson Ef fi cient interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Network latency, limited bandwidth In-memory, fast! vs. Must satisfy SLOs
43. @crichardson Prefer ACID over BASE System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Distributed, eventually consistent transaction Simple, Local ACID transaction vs. ACID txn ACID txn ACID txn
44. @crichardson Challenges of eventual consistency Operation = sequence of local ACID transactions About commands Typically implemented using the Saga pattern Sagas are ACD - lack Isolation due to interleaved execution Application must use countermeasures to implement Isolation About queries Implemented using API Composition or CQRS Query can return inconsistent results
45. @crichardson Minimize runtime coupling Runtime coupling between service A and B is the degree to which the availability of service A is affected by the availability of service B Order Service Customer Service POST /orders 1 PUT /customers/id Response 4 2 3 Tight runtime-coupling: lower availability ID Outcome
46. @crichardson Minimize runtime coupling System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Risk of runtime coupling, e.g. not meeting SLOs No runtime coupling: higher availability, lower latency vs. Must satisfy SLOs
47. @crichardson Customer Service Customer Subdomain Order Service Minimize design time coupling: avoid expensive lockstep changes Order Subdomain For zero-downtime deployments: 1. Change biz logic + Add new version of API 2. Migrate clients to new API 3. Remove old API Multiple commits
48. @crichardson Code repository Order Service Customer Subdomain Eliminate tight design time coupling between services Order Subdomain Customer Service Customer Subdomain Order Service Order Subdomain OR OK: Same repository Best: Package together But deployments aren’t atomic: API evolution issues
49. @crichardson Your context determines relevance of dark matter forces to your application Force: reason to NOT use microservices What determine relevance to your application Simple interactions Operation speci fi cation, SLO and design Ef fi cient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design coupling Service and operation design
50. @crichardson Summary Use DDD to de fi ne subdomains/bounded contexts BUT A service is a set of BCs/subdomains The microservice architecture is shaped by: Dark energy forces: encourage decomposition Dark matter forces: resist decomposition Trade-offs required https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the- fi rst-time Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for … SystemOperation() Generates Forces that act on subdomains and determine grouping into services
51. @crichardson @crichardson chris@chrisrichardson.net adopt.microservices.io Questions?