News for hackers. Stuff that matters.
Re:The C4 model for visualising software architecture by mannykannot on Saturday September 21, 2019 @10:21AM (#21035531)
From everything that I have seen, any software architecture modeling model that relegates dynamic behavior to a 'supplementary' status is suboptimal. One of the ways that waterfall fails is that the architects come up with an imposing, apparently comprehensive static structure that overlooks various issues that arise when it is put in motion. These points of contention often do not become apparent until one is trying to integrate the parts into a coherent system.

Software design is always an interation between static and dynamic matters -- use informs structure, and structure informs use.

Re:The C4 model for visualising software architecture by simon_brown on Sunday September 22, 2019 @07:02AM (#21040719)
> any software architecture modeling model that relegates dynamic behavior to a 'supplementary' status is suboptimal

Another explanation is that the static structure diagrams are what give the C4 model its name: Context, Containers, Components, and Code. These diagrams existed for a number of years, before the addition of the other diagram types, which themselves supplement the static structure diagrams.

That said, I don't find myself using the dynamic diagram type all that often. For software systems of any size/scale, I'm not going to create dynamic diagrams for every use case/user story/feature/etc. Instead, I'll use dynamic diagrams sparingly to describe overall patterns in use, significant use cases only, or complicated sets of interactions between things.

To prevent the issues you mention about overlooking issues, especially when doing any up front design, I recommend "dry-running" the significant usage scenarios across the static structure diagrams and/or running a risk identification exercise (e.g. risk-storming). Or you could use a formal architecture evaluation technique.