Evolving a microservice architecture using dark energy and dark matter forces
Let’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 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
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
- As part of the
- As part of the
Each of these three options has different trade-offs with respect to the dark energy and dark matter forces.
Coupon Service might improve team autonomy but it makes the
createOrder() operation, which redeems coupons more complex.
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.