Microservices and DRY code

We're talking architecture at work, specifically monoliths versus microservices. Martin Fowler has been posting some articles that we're talking about, including Start With A Monolith, no Don't Start With A Monolith, and Microservices Have Trade-offs. It's thought provoking, and good for hours of discussion, but in the end, all we really want is a good way to build performant, reliable, maintainable systems. And the key to all this is separation: we need to structure our code so that every moving part has all the pieces it needs, without creating any accidental and obstructive coupling between pieces that aren't intrinsically connected.


Microservices are one approach to separation, and a pretty effective one at that. Each microservice has its own separate data store, its own entities, and a well-defined interface for interacting with other microservices. This architecture forces you to think through your functions and entities to figure out what needs to be where, because once you put it in Service A, Service B can't easily get to it. Done right, each service is self-contained and self-sufficient.

Another approach is the DRY principle ("Don't Repeat Yourself"). The immediate goal of DRY coding is to simplify the task of maintaining your code. Cutting and pasting snippets of code may be easier, but if you ever need to change one copy, you have to search through and make the same change everywhere else, which is a pain, and error prone as well. Much better to extract all that code into its own function, which you can call from all the other places. Then when you need to modify it, you only change one place, and everything else is updated.

If you take a step back, DRY coding is another approach to developing the right separation of concerns. Why are you using the same snippets of code in so many different places? It could be that you haven't thought through your design well enough, and are mingling things that ought to be kept separate. Refactoring your code to make it DRY forces you to think about what it is you're separating out, and if you do it right, it can help you evolve a well-designed system.

If you set out to build a microservices-based system, you're approaching separation from the top down. When you refactor your code to make it DRY, you're approaching separation from the bottom up. Both approaches are valuable, but the important thing to remember is the separation of concerns that you're trying to get closer to. Then whether you're working at the top level, or the bottom level, or anywhere in between, you can focus on properly defining your entities and your functions, and the relationships between them.