Separation of concerns, separations of concerns, separation of concerns!

Can’t you just hear Steve Ballmer yelling this from stage?[0]

When you’re starting to piece apart a monolithic Django app, just figuring out where to start is often the hardest part. The key to getting started is identifying the implicit components of your app.

 

Models first

The place to get started getting started is your models module.

You’re more than likely going to separate more than models from your monolith, and in fact you’ll likely end up with models-free spin offs.

Not to mention the fact that your models will probably be the _last _thing to extract from the monolith itself.

However they provide the best insight into the foundation of your app. They typically represent the most important “things” in the world the monolith represents, and provide a pretty good hint as to what different domains you may be able to break it up into.

Pro tip: use django-extensions to generate a graph representation of your models and their relationships.[1]
 

Splitting across a horizontal axis

After assessing your models its time to move on to the rest of the monolith.

Your goal now is to identify different related groupings of functionality based on the problem solved. This could be a business domain problem (e.g. handling a specific workflow) or a technical problem in the app (e.g. how to serialize data from a proprietary file format).

There’s no clustering algorithm[2] for your codebase, but you should start to notice clustering of functionality.

It won’t be perfect and instead of bright lines demarcating these clusters you may see fuzzy boundaries. Expect this.
 

Going vertical: the hierarchy of needs

Instead of ending up with several groups of modules in parallel, you’ll likely find there’s common code that needs to be used by other modules.

There are a couple of ways to attack this in the end, but each involves lifting this functionality out of one module and making available “downstream”.

In some cases it may be obvious that there is a clear hierarchy in your modules, where one part of the monolith needs to know about another part (for example in a foreign key relationship).

In others though what you’ll find looks more like library code, utility functions and the like that are at least somewhat agnostic about the content of the original monolith and its future progeny.

Where this code is really specific to your project in some way lifting it into a ‘core’ or ‘home’ app often makes sense, but in most cases you’ll find a suitable library home - in your project - where the code need not “know” much or anything about the modules using it.

---

That’s the eagle’s eye view of approaching this. Next week we’ll look at some implementation tips for assessing the relationships and coupling in your Django monolith.

Overly generalized yours,
Ben

[0] From 2001 (a Microsoft odyssey): https://www.youtube.com/watch?v=oioj24KQRvM
[1] Graphing models https://django-extensions.readthedocs.io/en/latest/graph_models.html
[2] scikit-learn can do a lot elsewhere though! http://scikit-learn.org/stable/modules/generated/sklearn.cluster.KMeans.html

More like this

• This Old Pony: This is how you analyze your Django Monolith (for fun and profit)
• This Old Pony: Approaching the monolith