Software Architecture is fractal in nature. I’ve said this often; it goes down well in interviews. Try it.
By this, I mean that the way in which we design, and the way we make decisions on software, looks approximately the same at every tier. If we’re looking at a single code module, it’s formed of the same sort of design concerns as if we look at the whole architecture.
Don’t cross the streams, and try to bake the decisions from one layer into the work of a layer much lower down.
One of the key challenges in making good designs is being able to communicate them and validate them.
The Fix Box Diagram is your friend. Can you draw a picture of your design with boxes (they can be other shapes) and lines? Can you do it in approximately 5 boxes? If you can’t, why is it so complex? Have you gone into too much detail and can you simplify for this design discussion? Have you broken apart concerns too much? Are responsibilities scattered too broadly, rather than using the Single Responsibility Principle?
Some organisations put a lot of effort into documenting design. This used to be one of the weak practices of waterfall software development, but it can be turned into a powerful practice of Agile.
If you can’t draw your system on the back of a beer mat, then you don’t understand it.
The act of constructing a five box diagram will help you get your thinking clear about how the design functions, and whether it’s really buildable and testable. It will show you whether things have a single responsibility and, broadly speaking, answer requests, or whether you’ve got a crazy network of Chasing The Dragon.
On top of all of that, when you have a nice Five Box Diagram, you can use it as the image of your system that describes the context of your next software demo to your stakeholders.