search

ministryofjustice / hmpps-architecture-as-code

Modelling the software architecture of HMPPS Digital
https://structurizr.com/share/56937
Other
17 stars 3 forks source link

How to represent widely applicable C4 container concerns? #58

Open sldblog opened 4 years ago

sldblog commented 4 years ago

from https://github.com/ministryofjustice/hmpps-architecture-as-code/pull/56#pullrequestreview-469544950:

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 commented 4 years ago

@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?