Monolith waiting to be demolished
Moving from a monolith to a service oriented architecture is one of the architectural changes that we hear more often in web development. While some people believe this is what you should be doing if you want to modernize your application, others believe that if the monolith is working, is better not to touch it. I tried breaking a part of a monolith and I failed. This is what I learnt:
Focus on your main goal
Your main goal is refactoring your current application so that you can move to a service oriented architecture. It’s possible that the new architecture allows your app to do new functionality that before would have been really complex and you might be tempted to do it. Just don’t.
Breaking a monolith is not an easy task and the less distractions you have the better. You will have to deal not only with the use cases that you already had, but also with the complexity of managing interaction between service, testing the integration between them, etc.
Take an incremental approach
It is really tempting to create a new service from scratch, in its own repository, designing an awesome REST API and define how all the interactions with your monolith are going to look like. This is so much fun, you are working on an ideal service, perhaps using a new technology and everything seems great, but this will cause you a lot of trouble. Here is why:
- Your existing application is evolving and your ideal service functionalities might get outdated. Most likely you are not going to be able to do a code freeze.
- You don’t have a quick feedback from the users using your application, which means you don’t know whether or not what you have implemented works how they want.
Instead of doing this building from scratch, you should try to isolate the domain that you want to later on extract into its own service. Find the spots where the responsibilities of the domains that you don’t own are leaking into yours, as well as how your domain is leaking into other domains. Try to put a clean border in those places, making sure that the separation of concerns between domains are clear within the same app.
Talk to the stakeholders
I’ve found myself learning a lot from talking to the stakeholders in order to understand what are the needs of the experts on the domain I am trying to extract. For example, while it might come natural for you think that you have a domain leak into your domain and you just want to get rid of it, you might not realize that there is an actually need for that to exist. Propose your changes to the stakeholders, listen to them and then make the changes. Don’t overestimate the power of talking to the people who are using your system on a daily basis and are the real experts of what it should be doing once its divorced from the monolith.
Conclusions
If you are trying to break a monolith, or at least a part of it, remember that this is usually a complex task and you should protect yourself from adding new features while you are doing it.
Isolating your domain incrementally instead of using a design upfront approach will help you to have quick feedback and finding real problems that you would have not imagined if you were building your ideal service in parallel.
Lastly, talk to your stakeholders. Those are the ones who truly understand the domain you are trying to extract and will be really useful when doing some design decisions.