There are not many definitions of monoliths out there and they are often portrayed as the opposite of a microservice architecture or what not to do. They are sometimes perceived as: not a worthy architecture on their own. However many smaller systems could arguably be simpler if they were built as a monolith.
There are many definitions of microservices out there, but few of the monolithic architectural style. In this post I bring two definitions of monoliths.
Monolith as an intentional design
Many focus on size when it comes to defining whether a system has a monolithic architecture. You can use lines of code, complexity, number of endpoints or the like, however I like to use the following definition from "Microservices: Yesterday, Today, and Tomorrow" by dragoni et al:
"A monolith is a software application whose modules cannot be executed independently"
I would like to rewrite it to the following:
"a monolith is a software application which has more than one business capability"
As I interpret the modules part in the first definition as well modulated business capabilities. These are loosely coupled but cohesive units of code that each makes up a business capability. A business capability however, is a very loose term and is often different for every business area. An example of a capability could be invoicing as demonstrated at Capstera, where they define a business capability as:
a key component of business architecture, is an expression of what business does and can do. A business capability denotes the "What" a business can do, whereas a business process outlines how a particular activity gets done.
Another way to think of it is using the rule of single responsbility, if we have a service that is responsible for several business capabilities I would consider it a monolith. Sometimes it can be hard to decide whether a feature is an independent business capability or a small part of a business capability. In this situation I turn to what changes together stays together. If you have to change ten services every time you add or change business functionality, you have likely decomposed your architecture wrongly. As these services always change together they should be one application or at least less than ten individual applications. You have likely created a suite of nanoservices, which are even smaller than microservices.
Monoliths suffering from architectural erosion
Some look at monoliths as spaghetti code and this is often the case. It is well described by Rod Stephens in "Beginning Software Engineering":
"A software system is called ”monolithic” if it has a monolithic architecture, in which functionally distinguishable aspects (for example data input and output, data processing, error handling, and the user interface) are all interwoven, rather than containing architecturally separate components."
This definition is well written but I do not like this definition as it resembles an architecture gone wrong, rather than an intentional approach at creating an architecture. It is often the case with monoliths that their structure drifts away from the original ideas on how they should be organised. Over time monoliths can grow and become unmanageable, which creates a "resistance to change". As monoliths grow large they become difficult to replace and this can create vendor lock in. With microservices you can more easily swap out the technology or refactor a single microservice. If the business capabilities are entangled in a monolith it can be hard to refactor and this is where it starts to become the so called spaghetti or soup.
Again, I do not like to define monoliths this way as they can be well organised and have decoupled and cohesive modules. However it requires more discipline to keep the codebase clean as it is easier to accidentally entangle business capabilities with one another within a monolith. Everything is available and you can easily make a call to a module internal in another business capability. This can sometimes lead developers to make quick and dirty implementations (hacks).
Wrapping it up
This was my post on defining the monolith architectural style, I gave you two definitions which you may recognise from the field. Please write in the comments if you disagree with the definitions or have a third one you would like to add! I hope you enjoyed this post.
Further reading
As mentioned previously, microservices are often perceived as being the opposite of monoliths. If you are interested in microservices and how they are different from monoliths I would suggest Fowler and Lewis' webpage on the topic. If you are into books I would recommend Sam Newman's book on the subject - "Building Microservices":
Disclosure: Bear in mind that some of the links in this post are affiliate links and if you go through them to make a purchase I will earn a commission. Keep in mind that I link these companies and their products because of their quality. The decision is yours, and whether or not you decide to buy something is completely up to you.