Evolving a microservice architecture using dark energy and dark matter forces

application architecture   architecting   dark energy and dark matter  

---

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:

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.