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

Is the HMPPSSoftwareSystem interface good for our purposes? #52

Open sldblog opened 4 years ago

sldblog commented 4 years ago

It's used for defining systems:

https://github.com/ministryofjustice/hmpps-architecture-as-code/blob/57703d542bf2a605785917c15083e9d570bafd51/src/main/kotlin/model/NOMIS.kt#L9-L14

And it's used for defining a grouping for related teams:

https://github.com/ministryofjustice/hmpps-architecture-as-code/blob/57703d542bf2a605785917c15083e9d570bafd51/src/main/kotlin/model/InterventionTeams.kt#L7-L13

I've just realised we might have made HMPPSSoftwareSystem overly specific, as CourtUsers [...]

Note In the example, InterventionTeams

[...] wants to conform to the same interface but isn't a software system. That's not a criticism of this PR, and shouldn't block merge, but we may want to rename the interface or create a more appropriate one – I'm guessing that would have model entities and relationships, but not views?

Originally posted by @spikeheap in https://github.com/ministryofjustice/hmpps-architecture-as-code/pull/50

sldblog commented 4 years ago

I like the current interface and the flexibility it gives me. People are (in my mind) at the same level and importance of software systems, and it reinforces this.

I can't say if we will ever create views for people. The overhead of adding an empty function is probably lower than keeping in mind which interface to use (we could have one for model items, relationships and views and compose them based on need).

The way it is can also help with contributions: it's explicit where parts have to go without having to build a mental model of what interface/class to use.

Should we rename it but keep the functions as-is? (For now?)

spikeheap commented 4 years ago

Should we rename it but keep the functions as-is? (For now?)

I think that's the most sensible (read quickest, least impact) change. I agree that it's nice to treat people in the same way as systems, and we may end up wanting to generate views that revolve around them (?).

The cost of changing that later, or introducing a new interface, is pretty low too, so let's go with whatever feels right :)