software solutions / project leadership / agile coaching and training

Moving past the monolith, Part 1 – Organizing your code into modules

Posted on November 4, 2017

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.

No Comments »

No comments yet.

Leave a comment

I have over 15 years of software development experience on several different platforms (.NET, Ruby, JavaScript, SQL Server, and more). I recognize that software is expensive, so I'm always trying to find ways to speed up the software development process, but at the same time remembering that high quality is essential to building software that stands the test of time.
I have experience leading and architecting large Agile software projects and coordinating all aspects of a project's lifecycle. Whether you're looking for technical expertise or someone to lead all aspects of an Agile project, I have proven experience from multiple projects in different environments that can help make your project a success.
Every team and every situation is different, and I believe that processes and tools should be applied with common sense. I've spent the last 10+ years working on projects using Agile and Lean concepts in many different environments, both in leadership roles and as a practitioner doing the work. I can help you develop a process that works best in your organization, not just apply a prescriptive process.
Have any questions? Contact me for more information.
Ditching the Office - How an everyday corporate development team turned into a remote working team
From Stir Trek 2018
From Stir Trek 2017, cbus.js 2017
Iteration Management - Your Key to Predictable Delivery
From Stir Trek 2016 and QA or the Highway 2015
From CodeMash 2016, QA or the Highway 2014, Stir Trek 2012
The Business of You: 10 Steps For Running Your Career Like a Business
From CodeMash 2015, Stir Trek 2014, CONDG 2012
From Stir Trek 2013, DogFoodCon 2013
(presented with Brandon Childers, Chris Hoover, Laurel Odronic, and Lan Bloch from IGS Energy) from Path to Agility 2012
From CodeMash 2012 and 2013
(presented with Paul Bahler and Kevin Chivington from IGS Energy)
From CodeMash 2011
An idea of how to make JavaScript testable, presented at Stir Trek 2011. The world of JavaScript frameworks has changed greatly since then, but I still agree with the concepts.
A description of how test-driven development works along with some hands-on examples.
From CodeMash 2010
From CodeMash 2010