Evolving a microservice architecture using dark energy and dark matter forces
application architecture architecting dark energy and dark matterLet’s imagine that you are developing a microservices-based application and you need to implement a major new feature.
For example, your application consists of two services - Order Service
and Customer Service
- and you want to implement Coupon Management
:
The Coupon Management
subdomain needs to be part of a service.
But which service?
Blindly adding services leads to the More the Merrier anti-pattern
You might automatically implement Coupon Management
as a new Coupon Service
.
After all your application has a MICROservice architecture, which means lots of services, right?
The trouble, however, with blindly adding new services, is that it often leads to the More the Merrier anti-pattern.
An overly complex architecture that’s difficult to maintain and, perhaps, brittle.
Designing with the dark energy and dark matter forces
Rather than blindly adding new services, a much better approach is brainstorm various possible designs and evaluate them using the dark energy and dark matter forces.
For example, there are three possible ways to implement Coupon Management
:
- Separate
Coupon Service
- As part of the
Order Service
- As part of the
Customer Service
Each of these three options has different trade-offs with respect to the dark energy and dark matter forces.
A standalone Coupon Service
might improve team autonomy but it makes the createOrder()
operation, which redeems coupons more complex.
Alternatively, implementing Coupon Management
within the Order Service
simplifies createOrder()
but might reduce team autonomy.
It’s your job as the architect to evaluate and compare the designs and pick the best (or least-worst) one.
Melbourne platform meetup
To learn more, take a look at this presentation that I gave in January 2023 at the Melbourne Platform Engineering meetup.
Need help adopting microservices?
I provide consulting and training.