How to represent widely applicable C4 container concerns?

[sldblog]

from #56 (review):

My gut reaction was: could we add this to our HMPPSSoftwareSystem interface, so it becomes an attribute of our object rather than a functional wrapper? Obviously that doesn't work in this case because we want to add API doc URLs to containers as well as systems, so is it highlighting the need for a container abstraction?

This does make me wonder:

1. Should we be expanding our abstraction layer to include containers, and/or
2. Is this a useful abstraction to push upstream?

It feels like we're unlikely to be the only users of this building additional tooling for this, and it'd be amazing if what we build here could end up helping other Structurizr/C4 developers.

Anyway, they're more grand thoughts than a review! This is spot-on while we consider the wider architecture, as it'll make identifying and refactoring API URLs much easier if/when we need to.

[sldblog]

@spikeheap Currently, we seem to have a wide range of C4 containers "types": S3 buckets, databases, UI applications, backend applications with private APIs and apps with public APIs.

It's probably not applicable to push this into a top-level abstraction at this point.

I like the composability at the moment. Maybe we could create an abstraction just for representing C4 containers that are applications that expose public APIs? On the other hand, I like that every C4 container is defined the same way and I can add "annotations" and "aspects" in the .apply {...} block as needed.

My gut feeling is to wait until at least 90% of the landscape is mapped so that we see what patterns emerge. What do you think?