No man is an island, and no architecture is really complete within a single layer! I’ve written posts for each of the layers independently, and now I thought I’d pull it together and cover how I’ve shown the dependencies between them. First, for those who either haven’t seen them, or just want a handy link to them, the individual layers can be found here:

• Business Layer Patterns
• Application Layer Patterns
• Technology Layer Patterns

Realization (Realisation)

The first linkage between these layers are the “realization” relationships between an Artifact hosted within the technology layer (which represents the package, scripts, executables installed on a node) and the logical “Application Component”.

Here, this is a web application being realised by the underlying JAR or WAR packages, and a local application realised by the executable files on a desktop PC.

This is the same pattern used to show the software artifact realising the “System Software” element.

We can also see how a “<<Database>>” Artifact realises the logical “Application Data”, which in turn could realise a “Business Object”.

Serving

The serving relationship shows the dependencies between elements which are serve or are used by other elements (although the “used by” description is now deprecated, I still find it a useful term). This diagram shows the Application Component functionality which “serves” (is “used by”) the business layer, and a similar pattern where “System Software” provides services which serve the logical applications, e.g. database or email services.

Flow

Finally, there is the “Flow” relationship, and I will do a more detailed post in the future, which shows how data flows from system to system, or in this case between layers. I have found flow to be very useful in highlighting data flows around architectures, especially in a post GDPR world.

All together now

Putting all of these patterns together can allow an architect to build a model and views which can be used to walk all stakeholders through an architecture, highlighting complexity and concerns in a consistent manner.

Hopefully this is/has been useful. I hope to find the time to put a few more posts together with some examples covering the motivation, strategy and implementation layers, as well as specific models which I have used for data protections flows, etc.

As always, these examples are available on Github.