a good group of people, [but] it was hardly a definitive source of enterprise development expertise) vote on principles for software layering.
Some people take this exercise seriously. JohnLim describes the result of the vote as
excellent guidelines, while Paul Gielens adds his own vote. Others are more critical, including David Anderson and Rob Diana.
To my mind, even if you could collect up the most experienced people in the software world, I distrust the idea that you could get a coherent and meaningful set of architectural principles from a vote.
Architectural principles must come from reflective practice and/or grounded theory. For example, I can derive layering from a differential theory of change, as follows.
Purpose - What is layering supposed to achieve?
A well-layered artefact or system is more adaptable, because some types of variation can be accommodated within one layer without significantly affecting adjacent layers.
Form - What is the underlying structure of layering?
Boundaries between layers represent step changes with respect to some form of variation, from some perspective:
- Differential change over time
- A split between relatively homogeneous and relatively heterogeneous
Process - How do layers get established? Layers emerge from an evolutionary process, in which a series of small alterations affect the architectural properties of a system or (often unplanned and unremarked by the so-called architects).
- Redundant layers (where there is insufficient difference in variation between two adjacent layers) tend to gradually fuse together.
- Flexibility that is not used or exercised will attenuate.
- Engineers under time pressure will take shortcuts that compromise the official separation between layers.
- Where there is excessive differentiation within a single layer, this will tend to split apart, initially in an incoherent way.
Material - What is the source of a particular layering?
Layering comes from the experience of variation.
Related post: What's wrong with layered service models? (May 2009), Data Strategy - More on Agility (March 2020)
No comments:
Post a Comment