Explain the relationship between Context and Container diagrams

[aviflax]

Recently @kidpollo authored and published an FC4 Container diagram for an internal @FundingCircle system. I think it’s best for Container diagrams to be accompanied (and preceded by) Context diagrams, and since a Context diagram can be easily derived from a Container diagram, I went ahead and did that and contributed the Context diagram to that project’s documentation.

In the discussion of the contribution (on a pull request in a private repo) @kidpollo wrote:

I feel that the context diagram could be generalized more so it does not look so similar or repetitive to the more detailed component system. Maybe just mention the domains and remove the intermediate stuff like…

to which I replied:

@kidpollo your thinking makes a ton of sense, but I think it’s partly because I haven’t done a good job of explaining the value proposition of the context diagram, or more broadly, of having both the context diagram and the container diagram, and of them having a large degree of overlap. Sorry about that!

Let’s see if I can do that here and now, and if so then I’ll add this documentation to the FC4 methodology. (Upcoming changes to fc4-tool will make this the default and therefore easier to learn and practice.)

The concepts of the Context and Container diagram, their duality, and their close relationship all come from the C4 Model which is the foundation of the FC4 framework:

• C4 first defines a hierarchy of abstractions that defines Software Systems, Containers, and more
• It then defines its core diagrams:

  Visualising this hierarchy of abstractions is then done by creating a collection of Context, Container, Component and (optionally) Code (e.g. UML class) diagrams. This is where the C4 model gets its name from.

• Finally the key points:
  • A System Context diagram is:

    …a good starting point for diagramming and documenting a software system, allowing you to step back and see the big picture.

  • A really useful next step is to:

    …zoom-in to the system boundary with a Container diagram.

As I’ve been working with various folks to document a bunch of systems via these diagrams over the last year, I’ve observed that there’s a huge amount of value in this “zooming in” idea (which is implemented literally in the full Structurizr app) and I’ve observed that the zooming-in effect is most effective if the two images have enough overlap/duplication such that it’s kinda like an animation, in the sense that the things that don’t change seem stable and anchored, so one’s attention will focus on the things that do change.

Sorry that’s so long-winded, but my point is that these diagrams really complement each other best when they are somewhat duplicative — specifically when the context of the subject system is duplicated. That way those parts of the diagram remain stable and unchanging, enabling the viewer to focus.

In other words, when a viewer starts with a Context diagram, in which the subject system is collapsed, they can get their bearings first, and get a high-level view of the various other systems and parties with which the subject system interacts. Then, once they’re ready, then can hit next* and then the subject system will “explode” or open up, such that they can now focus on learning and understanding the set of containers that make up the system, and how they interact with each other and with the external (to the system) systems and parties.

I also included some animations to illustrate these ideas, but the animations depict private internal Funding Circle systems so I cannot include them here.

[aviflax]

I’m hoping this will be addressed via the new DSL we’re designing as part of Enhancement Proposal EP01 (#73).

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.