Thread by @evolvable

A thread about how to have a nicely-designed monolith. 👇

It’s probably obvious, but you need to split your monolithic codebase up internally. It might already be organised into directories/namespaces/packages of some type, but you might need to go further…

With a monolithic codebase, we need the ability to place fairly tight restrictions on who can see/use what. With compiled languages, this means having *separate compilation units* defined.

You *do not* want to carve your monolith primarily by technical layers - i.e. API/request handlers, services/business logic, repositories. A monolith is big. If you carve into a small number of modules, those layers will also be modules. Big is bad. We want SMALL, not big.

Worse than just big modules, though, with monoliths split into technical layers, we find to understand or change any process, you’ll likely have to traverse two or more layers. So the layers haven’t provided any CONTAINMENT in the job of understanding and modifying the code.

Ideally, with a well designed and segmented monolith, understanding and changing any particular piece of functionality will typically see the scope of that work limited to a SINGLE module of the codebase.

So, in the ideal monolith, a change to functionality will change a SINGLE module, and that module will be SMALL.

So if we don’t spilt a monolith by technical layers, how do we split? It should mostly be spilt into COMPONENTS of BUSINESS FUNCTIONALITY. Much like microservices, each component should take full responsibility for its small part of the business domain.

(I’m using weasel words like “mostly” here bc there are reasons to have technical layers sometimes, eg for generic, non-trivial technical services required by many components.)

There’s two main reasons a monolith codebase often feels like tracing through spaghetti:
• dependency on implementation; and
• circular dependencies

In splitting a monolith into components, there will be interactions required between the components. No business process is an island. What we want to do, though, is build small, clean internal APIs that components use to talk to each other.

Having APIs between components in a monolith prevents them from depending on each other’s implementation internals, providing containment of component internals. We’re teasing the big ball of spaghetti into smaller, acceptably bite-size balls of spaghetti.

Having prevented components from depending on each other’s implementation (commonly referred to as coupling) we still have to deal with the circular dependency problem.

This can occur because, now that APIs are separated from Impls, we can have Component A’s impl depend on Component B’s API, and Component B’s impl depend on Component A’s API.

This type of circular dependency is a coupling of domain knowledge. In a good design, one of these components won’t know that the other one exists. It should simply offer APIs that could be used by *any* other component.

One way to avoid it is to explicitly define the *runtime* dependencies between component impls and check for cycles. (Remember the compile time dependency is only on the APIs.)

If you discover a circular dependency that seems hard to get rid of, you either need to cut one of the components in two or pull out the Patterns book and deploy the Observer pattern or something similar.

And that’s pretty much it.
• Split into small components around business responsibility;
• Only let components depend on APIs, not impl;
• Eliminate circular dependencies.
Do all three well and your monolith’s Spaghetti Score will approach rock bottom.

All you need to do then is add in some laggy, unreliable network calls between components, and you’ve got microservices! 😜
#fini