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.
Learning Outcomes
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
Description
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.
Subscribe now to our Youtube channel and catch free new episodes every week.
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.
Originally published at www.essentialdeveloper.com.
Let’s connect
If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.
Top comments (0)