Designing Modular Systems: Difference between revisions
| Line 6: | Line 6: | ||
* [[Coupling]] | * [[Coupling]] | ||
* [[Cohesion]] | * [[Cohesion]] | ||
* [[DRY|Don't Repeat Yourself (DRY)]] | |||
=Overview= | =Overview= | ||
Revision as of 21:37, 3 January 2022
External
Internal
Overview
The larger and tightly coupled a system is, the harder it is to change, and the easier it is to break. The alternative is to compose a system from small, simpler pieces. Each piece has a clearly defined interface and it is easy to understand. The component can be tested and deployed in isolation. Microservices fall into this category.
The systems should be designed for modularity. The goal of modularity is to make it easier and safer to make changes to the system. The hope is that, for a well-designed modular system, you can make a change to a component without needing to change other parts of the system. A well-designed modular system performs well on these operational performance metrics.
Designing components is the art of deciding which elements of your system to group together and which to separate. Two important characteristics of a component are coupling and cohesion.
Coupling
In software system engineering, especially in systems based on microservices, we aim for loose coupling. In a microservices context, we want to avoid coupling the microservice and its consumers such that a small change to the microservice itself can cause unnecessary changes to the consumer.
DRY and Coupling
Use of shared (DRY) code between a client and a server can create tight coupling. More generically, if shared code leaks outside the service boundary, this leads to coupling.
As an example, a library of common domain objects that represent the core entities in a system and that is used by all the microservices in a system can cause to have to update all services if a change is made to it. If the services communicate via messages, the message queues also have to be drained to flush out content based on the old domain model, now invalid.