This is part of a series of posts about Moving Past The Monolith. To start at the beginning, click here.
One of the simplest things you can do to build modular software is simply to organize your code into modules. Every application can usually be grouped into sets of related functionality. The next step is to organize your code so that you put everything that you need for this group of functionality together, separate from the rest of the application. How far you go with this is up to you, and you have many options:
- Group code in a folder within a larger project containing many modules – may or may not have separate data layer code
- Separate assemblies (for you .NET folks)
- Separate deployments
Here are the questions that you need to ask:
- If I wanted to rewrite a module, how hard would it be? Would it be a relatively clean break or would I be trying to untangle a big ball of string?
- Do some modules change a lot more than others, or does it all change often?
- Do I get any benefit out of being able to deploy one module without another?
Keep in mind that there are trade-offs to everything. A simple trade-off is that if you’re on a .NET project and you split modules up into lots of projects, you’re compile times are going to go up because you have a lot more files to move around. For this reason, I typically don’t separate modules into separate projects unless I think there’s a chance that I might want either want to deploy them separately or unless I want to be able to have a separate solution file so that I can compile and develop that module without the others.
At the same time, if you are able to break up your .NET solution into more projects and then you are able to break up the solution into smaller solutions, now you can decrease compile time for developers (potentially drastically if you have a really large application).
Either way, you’re also going to end up with a more organized codebase that’s easier to navigate, understand, and change.
Read the next post in this series, Separating your data.