You are here

How to Transition Your App to a Service Based Architecture

Nearly every app starts as a monolith. But as the codebase grows, the app can become hard to understand for new developers and one small change in one part of the system can have unexpected effects in other places. This is where having a service-based architecture can help. The question is how to get your monolithic app into a manageable state so that you can start breaking it up into services. Jim Rottinger over at the Weebly Engineering blog explains how.  

Jim recommends taking three easy steps to put your monolith into a position where you can start breaking it into services. These steps are informed by the domain-driven design methodology. This is where you divide up code into components based on the business logic involved. So, for example, if you had a checkout app, you might want to create components based on payment processing, validation or tax calculations. The components that you create could then potentially become microservices. 

The first step Jim recommends is quarantining your business logic into different domains and eliminating dependencies between those domains. Quarantine here means not just putting different domain functions in different files (e.g. payment processing functions) but not letting those functions touch other parts of the app except via dependency injections. 

The second step is to define a tidy interface for each new component and hide the details. The advantage of this is that it means new developers can start working with your code immediately without worrying about how it works under the hood. The interface functions let him know what everything does. This is a good thing to do even if you have no wish to create a service-based architecture.

The third and final step is to use immutable value objects. These are objects that have properties like model instances. But unlike model instances, so long as two of them have the same values for their properties, they’re interchangeable. The advantage of using them in your app is that you can ship these objects around the different components and you’ll always know exactly how you can use them regardless of what other components have been doing with them.

Jim finishes by stressing that the most important thing to keep in mind is that you shouldn’t just jump into breaking up your monolith into services. You’ve got to transition it into a tidier state first. 

Be sure to read the next Microservices article: How to Establish a Reliable Microservice Security Strategy

Original Article

How to Organize your Monolith Before Breaking it into Services