Why does the violation count change when I collapse a cell on a Structure101 Architecture Diagram?

This will happen when there is one or more violations contained within the scope of the cell you are collapsing. For example you might have this situation:

And the violations count is show as 3(4) in the Diagrams list:

(i.e. there are 3 class-to-class violations, and a total of 4 when you count the detailed method-to-method dependencies etc.)

Now when you collapse the “orm” cell thus:

The #violations changes to 2(3).

This is because Architecture diagrams are used for you to articulate the dependencies in the codebase that you care about. The way you express what you care about is to expose it in a diagram. When you collapse the cell, the set of rules you are defining changes.

Why did we do it this way? Well it is very important that you have some way to express what you don’t care about as well as what you do. Otherwise should the rules checking also look inside all those other cells? And how deep should it check – to the immediate child containers, or all the way down to the leaf containers?

Another consideration is that Architecture diagrams are intended to be shared across your team. It would be just confusing if violations were being reported for rules that I can’t see in the diagram I see in my IDE, or the count of violations reported Sonar.

This can seem odd if you have done a bunch of layering work within a parent cell, and just collapse it temporarily while you work on the internals of another cell. But don’t panic. The work is not lost – it is retained in the Structure101 Studio diagram, and that cell collapse will not take effect unless and until you “publish” the diagram to the repository from which it is shared with the team. Also, the expansion icon on the cell changes from a “*” to a “+” to remind you that you have previously expanded the cell and it may contain stuff you want to expose before you do share the diagram.

We could have done this differently, but I still think we have the right balance between the potential downstream confusion, while still letting you temporarily elide detail as you’re working. What do you think?