[IEEE Software May 2010]
Buschmann, Henney
Architectural design is involved with making good high level design decisions. These decisions are selecting a 'good' option from a menu of viable options. Such decisions are improved when the following considerations are made :
Economy, Visibility, Spacing, Symmetery, Emergence.
Economy
Less code is better than more code. Don't over engineer. Recognise the essential, recognise the incidental. Don't focus on re-usability if it's not required. Simple interfaces, adhere to patterns if possible, but make an economic choice that "balances clarity, compression and abstraction. Clarity is achieved by reducing clutter, compression relates to the directness of design and abstraction relates to the removal of unwanted detail."
Visibility
The architecure, design decisions, mapping of the problem space to the layers of design should be visible. Perhaps obvious - so obvious that the architectural framework can not be mis-understood or ignored. This reduces architectural abrasion over time, and reduces learning curves. No design decision should be implicit, hidden.
Group associated things (good objects ?)
Use correct names for objects, types, variables, services, ...
Patterns that help with clarity are : Explicit interfaces, Strategy, Value Objects (??)
Spacing
Separation of concerns. Separation of design concepts. Layers ...
Prefer hierarchy separation and composition to (multiple ?) inheretance.
"Delegation through conceptual roots expressed as pure interfaces leads to a stricter, more separated layering."
- Functional responsibility separation => components
- Component usage perspective separation => role-specific interfaces
- Componnt group separation => layers and sub-systems
- Separation between contract and implementation => explicit interfaces and implementation choice possibilties
- Separation of commonalities and variabilities => stable frameworks, with well defined plugin concepts (i.e. flexible ?)
Symmetery
Symmetry is obvious, and simple to understand ... we can make reasonable predictions when symmetry is visible. We can expect consistency, alignment and balance - especially of opposites.
Examples:
- Object creation routines should be balanced with object destruction routines.
- Resource allocation and de-allocation (release)
- connect and disconnect
- open and close
There are, however, many cases where the asymmetry of the external context is best represented asymmetrically.
Emergence (self-organisation?)
I'm not sure I've understood all this section, but a central theme is to devolve control from a central manager, down towards general workers (threads). This inverts the design problem from "how is the workload divided into chunks that can be accomplished by simple machines?" to "how can I assemble simple machines that can work autonomously on chunks of the problem, and achieve the solution?"
The above set of considerations are NOT rules or fundamental principals, just points of view to assist in enumerating and evaluating design options.
Cross Referencing Considerations
- Symmetry is both bounded and revealed by economy
- Emergency is bounded by visibility, and in tension with visibility
- Spacing is reinforced and reduced by economy
- Visibility is balanced by spacing and restrained by economy
- Economy can reveal emergence and vice versa
- Emergence and symmetry both contradict and align
