Stop Trying to Turn Everything into a Service — Organize your Monolith First

3 domain-driven steps you can take to get your codebase into a more manageable state

Let’s face it, writing code to be part of a monolith is easy. We can query the database directly whenever we want, call whatever functions we want in other parts of the application, and not have to think much about organization because we are plugging into an existing architecture. The problem that this type of development leads to, however, is a fragile, entangled codebase in which any change to one part of the application can alter or even break something in some other part without anyone knowing why. Not only that, deploying becomes difficult, and it also creates an awful learning curve for new developers coming into the codebase. This is not desirable at all and many who find themselves in this situation begin to read about and understand the upsides of a service-based architecture (SOA). The problem is — the larger the monolith, the harder it is to break up.

But just because something is hard, does not make it impossible. That being said, it can feel impossible because it is not feasible to go from a messy monolith directly to an SOA. There has to be some kind of intermediary state we can get to that will make it easier to start breaking things up. This intermediary state is one that is still a monolith, but one that is organized by domain without the entanglement or fragility of our original codebase. Once we reach that point, it is much easier to make decisions about the future of our application, specifically in regards to deciding what to break out into services and what parts should remain together.