Because I like to share knowledge
This post is about chapter 5: Building block view, the second chapter in the “How is it built and how does it run” group.
Chapter 4 set direction; chapter 5 makes it tangible. Here you describe the static structure of the system: the building blocks, what each one is responsible for, and which dependencies matter.
The goal is not to document everything. The goal is to give readers a mental map of the solution, so changes and discussions stop happening “in someone’s head”.
This post opens the “How is it built and how does it run” group.
The first three chapters can feel like silos: each one introduces its own set of information. Here, those inputs start to shape the design. This is where you set direction for the solution.
Your solution strategy should fit the goals from chapter 1, operate within the non-negotiables from chapter 2, and respect the boundaries and partners from chapter 3.
Early in a project this chapter can be short. That is normal. The strategy grows as you learn, as constraints become concrete, and as decisions are made.
Chapter 3 is the last chapter in the “Why and where” group. It is where you draw the line between your system and the outside world.
If that line is unclear, failures show up eventually: unclear responsibilities, failing integrations, and mismatched expectations.
This chapter is split into two views:
Chapter 2 is part of the “Why and where” group. It is the chapter where you write down the rules you cannot break.
This is not about what you prefer. It is about what your organization, environment, or stakeholders already decided for you.
If you do not document constraints early, they still shape the architecture. You just discover them at the worst possible time.
Constraints also have a positive side: there are thousands of ways to build the same functionality. A short list of non-negotiables helps you narrow down options early, before you invest in the wrong direction.
I have seen teams pick a public cloud technology because it fit the solution, while the product had to run air-gapped on-premises.
Or because it was “hot” (call it: conference-driven design), while operations would only support a single platform.
Money got wasted before someone finally said: this was never negotiable
.
Chapter 1 is part of the “Why and where” group. The audience for this chapter is everyone involved in the project. Even nontechnical stakeholders should read and understand it.
It is the chapter that can prevent a lot of confusion later. You lay the foundation for everything that follows. Not by adding too much detail (there are other chapters for that), but by making the intent explicit.
If you do not know why you are building this application and who it is for, you and your team cannot design it properly.