Moving past the monolith, Part 8 – Planning ahead
This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here.
Most of us are well-intentioned and never set out to create the giant monolith that weighs down the entire company, but it continues to happen everywhere. After making the mistake many times myself, I’ve realized that they only way to stop this from happening to be more proactive.
We need to discuss modularity when we start creating applications. We need to discuss it any time we move into a new set of functionality. We need to discuss it throughout the life of the application before we get past a point of no return. We need to be thinking now about how someone is going to need to replace the code that we’re writing today.
We can’t just write up a bunch of tickets and have a bunch of developers write code over many years and expect that we’ll end up with something modular. This will always lead to a monolithic application. The only way to avoid this is to make modularity an important design consideration.
This might mean changing how we design our domain models, creating copies of data that are sourced from a master copy, creating service boundaries between modules (either physical or logical), and possibly doing a little more work to protect your ability to change.
This is something your whole team needs to be aware of. Your leads might not know about that code that blurs the module boundaries until it’s too late and you don’t have time to refactor the code. Everyone needs to understand why you’re building modular code and how you plan on doing it.
My experience with modularity
After building many monoliths, I’ve been using these concepts on my current project, and we are reaping the benefits. We have many different deployable modules, and several different solutions (less compiling!). We have modules on very different deployment schedules — some deploy when needed, some deploy on regular schedules, and some don’t deploy at all. Some have modular code but need to be split out into their own deployments so that they can be deployed independently. Some of our code still feels monolithic — some projects are hard to change, take a long time to compile, and some of it is on our list of things to refactor, but since it’s not built in a modular way, do so is proving to be difficult.
I’m really excited about where we are headed, and I’m more confident than ever that we’re going to be able to build large enterprise applications without creating a monster or ending up with a giant .NET solution that takes 3 minutes to rebuild.
I would love to hear from anyone else taking this approach, and I would love to know how it’s going for you and what lessons you’ve learned. I imagine I will look back on this post a year from now and want to make a lot of edits based on things that I’ve learned. I’m OK with that, that just means that I’m learning, and learning is a good thing.
If you’ve made it this far, thank you for joining me on this journey! I hope that something in here will empower you to start creating more modular and maintainable software.
Leave a Comment