Modularization

Nowadays, Microservices, Bounded Context, etc. are talked about in mostly software architecture and design topics. Essentially, they are buzzwords for modularization, decomposing a system into modules with the hope for faster time to market which is one of key success factors for implementing any architecture and patterns.

There is an excellent paper from Carnegie Mellon University written in 1971 talking about this topic. The thoughts are still applicable to our current design and architecture, like Microservices, Bounded Context.

There are different ways to divide the system into modules, Parnas suggested to look at following aspects / goals when making a decision.

• Development time could be shortened because separate groups would work on each module with little need for communication
• It was hoped that the system could be studied a module at a time with the result that the whole system could be better designed because it was better understood
• It was hoped that it would be possible to make quite drastic changes or improvements in one module without changing others

No matter what approach to modularization you use, a module

• solves one problem and does it well;
• provides an abstraction that reveals as little as possible about how — the design decisions — to solve the problem and leads to loosely coupled modules; for instance, shared storage access is an anti-pattern;
• has a high cohesion that encapsulates everything related to the problem.

The most common approach to modularization is flowchart where modules correspond to steps. It is easy and straightforward, and it is what we are taught in university. However, more than one module may know / depend upon same design decisions which makes it difficult to achieve the second goal.

A different approach is one design decision is hidden by one and only one module (Single Responsibility Principle applies here as well).

The paper proposes the second approach as it allows us to build a system with modules towards the goals above.

The modularizations are intended to describe the design decisions

Within each module / bounded-context / Microservice, there lives Aggregates that are exposed as RESTful APIs or Functions.

The two recent projects that I have done and use this principle are Messaging and PayProtect.