Software components diagram
In order to address some of the issues highlighted in the previous section, I’ve modeled the same system by focusing on software components. This does not follow any specific standard even if is pretty similar to the C4 approach (where C4 stands for Context, Containers, Components, and Code; we will discuss this further in later chapters):
Figure 1.8 – Software components diagram
As you can see, this schema is more homogeneous and better organized than the first sketch. At a first glance, you can view what features are provided to the user. Additionally, it highlights how the system interacts with each other in a structured way (for example, using API calls, reads and writes, and more).
Compared to the first sketch, there are some considerations that we can observe:
- The components are almost the same as the other schema.
- The diagram is less focused on the use case, even if the user is still represented (together with a high-level recap of the features available to them).
- There is no view on the project phases. This helps you to focus on just one point of view (architectural components), making the schema less confusing.
- No protocols are named, only high-level interactions (such as reads, writes, and API calls).
- Some technical components are preserved (the database), while others are skipped since they have less impact on the functional view (for example, the CDN, which is probably more relevant on a network schema).
In this section, we learned how to approach the first design of our mobile payments application; first, with a more naïve view, then by trying to detail the view in a more structured way. In the upcoming chapters, we will discuss how to further clarify and enrich those views.
