In this video, Nick Maiorano compares monolith vs. modular systems, as well as the five pillars of modularity and the benefits they bring to software engineering.
- Modularity is an important concept in software engineering. It creates structure inside large software systems by allowing them to be decomposed into smaller and more manageable pieces. The absence of modularity makes a system monolithic. No system is ever said to be completely modular or completely monolithic. They're just two extremes of the continuum. Modularity may not be too important at a small scale, but it becomes more and more critical as systems become larger and more complex.
In fact, without modularity software systems collapse under their own weight. What's worse is that this doesn't necessarily happen overnight but it's a slow and steady descent into chaos. So how do you know if your system is not modular? Changes become difficult because they have huge ripple effects across the system. Building and employing the system takes longer because of its size and one area requires a whole process to start over again. And of course large monoliths are brittle upon execution because it only takes one failure to bring the whole thing down.
Monoliths also make outsize demands on resources such as memory and disk. In short, the large monoliths run contrary to everything we hold dearly in software modern engineering. Like most abstractions in software engineering, modularity is difficult to pin down into an exact definition. But we could think of a few qualities that modularity has in order to better define and understand what it is. Modularity includes the notion of encapsulation. That is the subsystem where a module within the system is able to protect outside access to its internals.
Encapsulation ensures that control is restricted from the outside so that the module can properly function. This doesn't mean that the outside world has no say on how the module works. But rather that the encapsulated module controls what the outside can see and do. Implied in the definition of modularity is the expectation that individual modules can work with each other and in are interoperable. Modules define points where they can interface with each other.
A non-interoperable module runs counter to the principles of modularity. A byproduct of interoperable software is a composable system. That's the idea that the individual modules can be used in different ways to create new collective poles. Systems can even be configured in ways that were not envisioned by their creators. Modular systems are also said to be expandable. This inherited quality of modular systems. Expandable systems allow individual pieces to be added to the composable system and increase or decrease capacity.
Either alone or when combined. Autonomy is another important aspect of modularity. This is the notion that each part of a system can work independently. One of the benefits of this is that autonomous system can keep working even if other modules fail. In this way, modular systems can contain failure. The qualities of being encapsulated, interoperable, composable, expandable, and autonomous. Make up the five pillars of modular systems.
In this course, instructor Nick Maiorano breaks down this complexity by explaining what modularity is all about, how Java has adopted modularity and how to start using to build better quality applications.
- What is modularity?
- The five pillars of modularity
- Modularity in the real world
- JPMS concepts and syntax
- Designing and implementing a modular structure
- Compiling, packaging and running modular applications
- Using the dependency checking tools
- Creating custom runtime images
- Managing backward compatibility with classes and modules
- Explicit, unnamed, and automatic modules
- JPMS tips and recommendations