Dark matter and dark energy are mysterious concepts from astrophysics that are used to explain observations of distant stars and galaxies. The Microservices pattern language - a collection of patterns that solve architecture, design, development, and operational problems — enables software developers to use the microservice architecture effectively. But how could there possibly be a connection between microservices and these esoteric concepts from astrophysics? In this presentation, I describe how dark energy and dark matter are excellent metaphors for the competing forces (a.k.a. concerns) that must be resolved by the microservices pattern language. You will learn that dark energy, which is an anti-gravity, is a metaphor for the repulsive forces that encourage decomposition into services. I describe how dark matter, which is an invisible matter that has a gravitational effect, is a metaphor for the attractive forces that resist decomposition and encourage the use of a monolithic architecture. You will learn how to use the dark energy and dark matter forces as guide when designing services and operations.

1. @crichardson
Dark energy, dark matter and
the microservice architecture?!
Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
@crichardson
chris@chrisrichardson.net
adopt.microservices.io
Copyright © 2022. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson
COVID work life since March 6th 2020…

3. @crichardson
“The software architecture of a computing system is the set of structures needed
to reason about the system, which comprise software elements, relations among
them, and properties of both.”
Documenting Software Architectures, Bass et al
Development
• Maintainability
• Testability
• Deployability
• …
Architect
Nonfunctional requirements
Runtime
• Scalability
• Performance
• Availability
• …
Satis
fi
es
De
fi
nes
Architecture

4. @crichardson
Monolith or Microservices?
In reality: it depends
BUT
On what?
ask Twitter!

5. @crichardson
Presentation goal
How dark energy and dark matter
help create a better architecture!

6. @crichardson
About Chris
http://adopt.microservices.io
Late 80s 2006 2008 2009
2012-

7. @crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Architecting with dark energy and dark matter

8. @crichardson
Suck/Rock Dichotomy
http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html

9. @crichardson
Patterns: a better way to
reason about architecture
Reusable solution
to a problem
occurring
in a context
and its consequences

10. @crichardson
Alternative
Pattern
The structure of a pattern
Pattern
Bene
fi
ts
Drawbacks
Issues
Alternative
Pattern
Patterns
that
address
issues
Context
Problem
Solution
aka the situation
(con
fl
icting) issues/
requirements/etc to
address
Forces
Consequences
predecessor
successor

11. Pattern language: collection of
related patterns in a domain
http://en.wikipedia.org/wiki/A_Pattern_Language
Access to Water
Promenade
Local townhall
Intimacy gradient
Light on two sides
Alternative
Pattern
Pattern Issues
Alternative
Pattern
Patterns
that
address
issues
predecessor
successor

12. @crichardson

13. @crichardson
Pattern
The pattern language guides you
when developing an architecture
Pattern
Pattern
Context
Problem
Forces
Consequences
Pattern
Solution
Issues
Select
Find
applicable
patterns
Repeat
Problem
Context
Updated
context
Sub-
Problem
Matches
Solves
Assess trade-offs
Pattern
Solution

14. @crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
Application
≪service≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪ service ≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪service≫
…
Browser
Order
Database
User
API Gateway/BFF
Kitchen
Database
Message
broker
Application.JAR
≪module≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪module≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪module≫
…
Browser Database
User
Microservices
Monolith

15. @crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution

16. @crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution

17. @crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Dark energy and dark matter in action: an example

18. @crichardson
How to de
fi
ne an
Architecture…
Application
≪subdomain≫
Customer
management
≪aggregate≫
Customer
≪subdomain≫
Order
management
≪aggregate≫
Order
createCustomer()
createOrder()
fi
ndOrder()
fi
ndOrderHistory()
System operations
Distill
Requirements The “requests” that the
application implements
Have SLOs
Customer Team
Order Team
About Subdomains
• Business capability/function/etc
• Logical view: packages and classes
• Team-sized
• Loosely coupled (Conways law)
1
2
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
Available
Restaurants
Restaurant
Menu
System quality attributes
• SLA: Reliability/Latency
• Scalability
• …

19. @crichardson
Kitchen Service
Delivery Service
Order Service
createOrder()
… how to de
fi
ne an Architecture
createOrder()
<<subdomain>>
Order Management
Order
System operations
<<subdomain>>
Order
Management
<<subdomain>>
Kitchen
Management
<<subdomain>>
Delivery
Management
<<subdomain>>
Courier
Management
Group
subdomains
into services
Application
Collaboration
Design
collaborations
for distributed
operations
createOrder()
3

20. @crichardson
Grouping subdomains into
components: together or separate?
≪subdomain≫
Customer
≪aggregate≫
Customer
≪subdomain≫
Order
≪aggregate≫
Order
Attraction
Repulsion
Simple components
Team-sized services
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, ef
fi
cient interactions
Prefer ACID over BASE
Minimize runtime coupling
…
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
Generate
systemOperation()

21. @crichardson
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 matter forces

22. @crichardson
Simpler components/services
Service
Service
Service
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
More complex service
Simpler services: easier to
understand, develop, test, …
versus

23. @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

24. @crichardson
Fast deployment pipeline
@mipsytipsy
https://speakerdeck.com/charity/cd?slide=17
Service
Subdomain
Subdomain
Service
Subdomain
Shorter
lead time
Simpler
build
Longer lead
time
More complex
build*
* Parallelizing building/testing partially helps
Service
Subdomain
vs.

25. @crichardson
Support multiple technology
stacks
Service
Python
Service
Java
Service
JVM
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
Single technology stack
Upgrade together
Separate technology stacks
Right tool for the job
Upgrade independently
Experiment easily
versus

26. @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

27. @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!

28. @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

29. @crichardson
Attractive forces
subdomains in same service
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.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
Generates
SystemOperation()
Collaboration

30. @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.

31. @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

32. @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

33. @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 No runtime coupling: higher
availability, lower latency
vs.
Must satisfy
SLOs

34. @crichardson
Minimize design time coupling
Order
Subdomain
Customer
Subdomain
reserveCredit()
createOrder()
Customer
Order
Design-time coupling
Minimize with careful design
BUT
You can’t always eliminate it
Risk of lock step changes
API
Risk proportional to:
• API instability
• API complexity
• …

35. @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

36. @crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Dark energy and dark matter in action: an example

37. @crichardson
Classic layered Monolithic architecture
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
«Gradle Subproject»
web
web
.customers
web.orders
«Gradle Subproject»
domain
domain.
customers
domain.
orders
«Gradle Subproject»
persistence
persistence.
customers
persistence.
orders
Customer team
Order team
Deployment pipeline
Production
FTGO
Application
Executable JAR
Technical
layers

38. @crichardson
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
«Gradle Subproject»
orders
orders.web
«Gradle Subproject»
customerAPI
orders.
domain
«Gradle Subproject»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment pipeline
Production
FTGO
Application
Executable JAR
customers.
domain
customers.
web
customers.
api
Modular monolith: domain-oriented
De
fi
nes API
Vertical slices/domains
Clear ownership

39. @crichardson
Monolithic architecture: bene
fi
ts and drawbacks
revisited
Repulsive forces
Simple components ✅ or ❌ ∝1/ size
Team autonomy ✅ or ❌ ∝1/ size
Fast deployment pipeline ✅ or ❌ ∝1/ size
Support multiple technology stacks ❌
Segregate by characteristic ❌
Attractive forces
Simple, ef
fi
cient interactions ✅
Prefer ACID over BASE ✅
Minimize runtime coupling ✅
Minimize design time coupling ✅
Modularization + build technology
enable the Monolithic Architecture to be
used for larger applications
BUT
the application can ultimately outgrow its
architecture when these forces cannot be
resolved
It can’t resolve these forces

40. @crichardson
Microservice architecture:
Many components
Production
Github Repository
Github Repository
«Gradle project»
orders
orders.web
orders.
domain
«Gradle project»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment
pipeline
«Executable JAR»
Order
Service
customers.
domain
customers.
web
customers.
main
orders.main
«Executable JAR»
Customer
Service
Deployment
pipeline
«Service Instance»
Order
Service
«Service Instance»
Customer
Service
Inter-service
Communication

41. @crichardson
Operation => one or more services
Service
Subdomain
Subdomain
API
Gateway
operation()
Collaboration
Aggregate
Service
Subdomain
Subdomain
Aggregate API Composition
Provider
Service
Service
query()
Composer
Provider
Service
Provider
Service
CQRS
Provider
Service
Service
query()
View
Provider
Service
Provider
Service
Event
Event
Event
Service
Service Service
Transaction
Compensating
transaction
Transaction
Compensating
transaction
Transaction
Compensating
transaction
command()
Saga
Collaboration patterns

42. @crichardson
Microservice architecture: Bene
fi
ts and drawbacks
Repulsive forces
Simple components ✅
Team autonomy ✅
Fast deployment pipeline ✅
Support multiple technology stacks ✅
Segregate by characteristics ✅
Attractive forces
Simple, ef
fi
cient interactions ❌
Prefer ACID over BASE ❌
Minimize runtime coupling ❌
Minimize design-time coupling ❌
Must design services
and collaborations to:
• Maximize bene
fi
ts
• Minimize drawbacks
Potential bene
fi
ts
Potential drawbacks

43. @crichardson
Designing the Food To Go architecture
Order Service
<<subdomain>>
Order
Management
Restaurant
Service
<<subdomain>>
Restaurant
Management
Kitchen Service
<<subdomain>>
Kitchen
Management
… Service
<<subdomain>>
…
acceptTicket(ticketID, readyBy)
noteAccepted(readyBy)
scheduleDelivery(readyBy)
createOrder(…)
Ranked operations
<<aggregate>>
Ticket
<<subdomain>>
Delivery Management
<<aggregate>>
Delivery
Services
already
de
fi
ned
To group into
services
createOrder(…)
…

44. @crichardson
Designing acceptTicket()
Kitchen
Service
Kitchen
Management
Ticket
Delivery
Management
Delivery
Kitchen
Service
Kitchen
Management
Delivery
Service
Ticket
Delivery
Management
Delivery
✅ resolves dark matter forces
❌ violates dark energy forces
• Simplicity
• Team autonomy
• …
acceptTicket() acceptTicket()
✅ resolves dark energy forces
• Simplicity
• Team autonomy
• …
⁈ Dark matter forces
Local
Complicated
Complex
Distributed
How to update Ticket and create Delivery?
???

45. @crichardson
Saga
Classic 2PC/XA
txn
Bene
fi
ts
Drawbacks
Issues
Context
Problem: how to implement a distributed command?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution

46. @crichardson
Bene
fi
ts and drawbacks: 2PC vs. Sagas
2PC Saga
Repulsive forces
…
Support multiple technology stacks ❌ ✅
…
Attractive forces
Simple, ef
fi
cient interactions ? ?
Prefer ACID over BASE ✅ ❌
Minimize runtime coupling ❌ ✅
Minimize design-time coupling ? ?
Must design saga to
minimize drawbacks

47. Saga design determines
resolution of dark matter forces
T1
T2
…
C1
C2
…
Saga design decisions
Saga
Simple, ef
fi
cient interactions
Prefer ACID over Base
Minimize design-time coupling
Step de
fi
nition and ordering
Choreography or orchestration
Select countermeasures
Dark matter

48. @crichardson
Accept Order saga design
T1: noteAccepted()
T2: scheduleDelivery()
Ticket accepted
acceptOrder()
Ticket events
channel
Kitchen
Service
Delivery
Service
Attractive forces
Simple, ef
fi
cient interactions ✅
Prefer ACID over BASE ✅*
Minimize runtime coupling ✅
Minimize design-time coupling ✅
* ACID-ish

49. @crichardson
Summary
“Should I do X*?”
“It depends!”
“Depends on what?”
“Dark energy and dark matter forces”
https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the-
fi
rst-time
* X - related to Microservices

50. @crichardson
@crichardson chris@chrisrichardson.net
adopt.microservices.io
Questions?