This Old Pony: Approaching the monolith

Do you know what the most common “legacy” pain point is in existing Django projects?

I’ll give you a hint:

If you guessed “monolith”0 you’re right on the money.
 

The Django app monolith

Monolithic Django _apps _grow in projects of all ages, whether they’ve just launched or have been running in production for years. They’re easy to dismiss early on because the pain, and costs, come later.

Let’s make sure first that we know what we’re talking about here. By Django apps _we mean the modules you include in your Django _project. As the docs so nicely put it:

Applications include some combination of models, views, templates, template tags, static files, URLs, middleware, etc. They’re generally wired into projects with the INSTALLED_APPS setting and optionally with other mechanisms such as URLconfs, the MIDDLEWARE setting, or template inheritance.1

So Django apps _are just the modules used to compose a Django project. And a _monolithic _Django app is one that grows to include more and more functionality that by all rights _belong in separate Django apps.
 

But I like everything in one place…

Aside from having a general feeling of disorganization, it may not be obvious why monolithic apps are a problem. If this is a closed source project with a proprietary use case, who cares if the functionality is jammed into one module?

The pain and costs of monolithic apps extend beyond aesthetics. By erasing a separation of concerns, monolithic apps tend to:

• Make testing slower and more challenging
• Foster architectural fragility
• Reduce code reuse
• Make feature updates slower and more difficult
• Make developer onboarding more difficult
• Hide areas of improvement These are all real costs that affect development teams and the businesses behind them.
   

  Redistributing the monolith

  When I say this is a common pattern in working Django projects, I mean that. We’ve come across some version of this in _every existing Django project _we’ve worked on in any capacity. This includes big projects with dedicated developer teams to small projects with small teams.

It’s not something to beat yourself up over having. As long as you address it before you calcify your entire project!

So how do you address the monolith?

Divide and conquer, obviously!

Beyond that it involves understanding the various business domains of your project, spending some time analyzing both patterns in the code and the development process, and then the sometimes-sticky process of moving code and actually implementing a proper hierarchy of apps.

Over the next few weeks we’re going to dive into some strategies for approaching your monolith and some down-and-dirty implementation tips for turning your monolithic Django app into the foundation of a high-powered Django project.

We’re going to continue  examine the Django app monolith over the next few emails, including

Monolithically yours,
Ben

More like this

• This Old Pony: Hacking the Django monolith
• This Old Pony: A framework to assess software & service lock-in