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.
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
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
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
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
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
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
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
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
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
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(…)
…
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