software solutions / project leadership / agile coaching and training

Moving past the monolith, Part 5 – Minimizing sharing between 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.

We’ve been talking about how you can break your application up into modules, which are groupings of functionality that can function (and potentially be deployed) as a semi-independent unit. In most cases, you’re probably still going to have a decent amount of shared code, database tables, CSS, and JavaScript code that needs to be shared across all modules.

I have no problem with the “shared module” that everyone ends up creating. This is a necessary part of every application, and by no means would I encourage you to copy and paste code. :) As always, there are some things to consider:

  • Are you putting something in a shared module just because you think it will be shared or because you know it will be shared?
  • These shared modules are for sharing within your application, never outside your application. If you need to share things with other teams, create services, database schemas, or something special for those teams.
  • Understand that every time you put something in a shared module, any changes to that code could impact any number of modules using it, which may involve you having to change, refactor, and deploy many other modules. The benefits will typically outweigh the downsides, but make this a conscious decision.
  • Pay attention to situations where you starting seeing so much related functionality in the shared module that maybe you need to birth a new module out of it.

One of the goals of modular software is making change, refactoring, and replacement easier. Shared modules can help you achieve your goals when used within reason, but make sure you remain aware of what’s going on so that you don’t end up with too much tight coupling.

Read the next post in this series, Using package managers to share common code.

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