In this episode, we zoom out from the component level view of the system created previously and we showcase how to organize it into modules.
- Understand the representation of relationships of components and modules in a diagram
- Understand how concrete or modular a system is from its diagram representation
- Understand that every system needs to be tailored, rather than fit a predefined template
- Understand that the process of abstracting needs to be applied incrementally
We start things off by substituting the type names in the diagram with the name of the modules they belong to. For example, the
FeedViewController can belong to a
UI module, since it is responsible for rendering views and gathering user interactions, and the
RemoteFeedLoader to an
API module, as it is responsible for communicating with the network.
Moreover, we demonstrate various kinds of organization and modularity levels, and finally, we examine the case of the famous monolith, where all components belong to a single module and discuss possible tradeoffs.
Understanding the tradeoffs and risks that each design brings can be a tremendous asset while moving forward with the development of our systems. As developers and risk managers we shouldn’t be searching for one-to-rule-them-all kind of solution (it doesn’t exist); instead, we can tailor a solution based on the available resources and requirements.
Originally published at www.essentialdeveloper.com.
We’ve been helping dedicated developers to get from low paying jobs to high tier roles — sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.
If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.