Profile picture
Graham Lea @evolvable
, 19 tweets, 3 min read Read on Twitter
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! 😜
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Graham Lea
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!