Based on the master thesis from Andreas Martens supervised be me, we defined an abstract 7‐Layer‐Software‐Architecture. The idea behind this is to understand the mapping of possible components and libraries onto the landscape of software architecture. The 7‐Layer‐Software‐Architecture is also a kind of checklist for none‐functional issues like state propagation and data transformation. Each enterprise application (and so its components) can be divided logically into this 7 layers. Onto or between these layers you can find libraries like Hibernate (OR‐Mapper between Domain Data model and Abstract Data model). Depending on the IT architecture these layers getting mapped into one or more tiers.
An enterprise web application can own three tiers (see CheatSheet at the bottom):
- the browser which renders the HTML pages and the user can interact with
- an application server which owns the Domain Logic (business logic), and so also the Domain Data model and the dialog definitions with all its widgets
- the database server which stores data into tables and physically using bits and bytes onto a hard disk
For a software architect, it is important to take care of the streams between layers (and so tiers). There are four streams: Action (sending, like a button‐click), Data (presentation and modification), State (presentation and modification) and Error (receiving).
Between each layer, a software architect must check, if a validation, transformation, propagation and many more is needed. If these flows are divided by two tiers, the architect must also take care of network transportation, network security and many additional issues (for more details see CheatSheet).
The 7‐Layer‐Software‐Architecture CheatSheet can be downloaded here (V 1.3):