Guidelines: Layering
Topics
Layering provides a logical partitioning of subsystems into a number of sets,
with certain rules as to how relationships can be formed between layers. The
layering provides a way to restrict inter-subsystem dependencies, with the result
that the system is more loosely coupled and therefore more easily maintained.
The criteria for grouping subsystems follow a few patterns:
- Visibility. Subsystems may only depend on subsystems in the same
layer and the next lower layer.
- Volatility.
- In the highest layers, put elements which vary when user requirements
change.
- In the lowest layers, put elements that vary when the implementation
platform (hardware, language, operating system, database, etc.) changes.
- Sandwiched in the middle, put elements which are generally applicable
across wide ranges of systems and implementation environments.
- Add layers when additional partitions within these broad categories
helps to organize the model.
- Generality. Abstract model elements tend to be placed lower in the
model. If not implementation-specific, they tend to gravitate toward the middle
layers.
- Number of Layers. For a small system, three layers are sufficient.
For a complex system, 5-7 layers are usually sufficient. For any degree of
complexity, more than 10 layers should be viewed with suspicion that increases
with the number of layers. Some rules of thumb are presented below:
# Classes |
# Layers |
0 - 10 |
No layering needed |
10 - 50 |
2 layers |
25 - 150 |
3 layers |
100 - 1000 |
4 layers |
Subsystems and packages within a particular layer should only depend upon subsystems
within the same layer, and at the next lower layer. Failure to restrict dependencies
in this way causes architectural degradation and makes the system brittle and
difficult to maintain.
Exceptions include cases where subsystems need direct access to lower layer
services: a conscious decision should be made on how to handle primitive services
needed throughout the system, such as printing, sending messages, etc. There
is little value in restricting messages to lower layers if the solution is to
effectively implement call pass-throughs in the intermediate layers.
Within the top-layers of the system, additional partitioning may help organize
the model. The following guidelines for partitioning present different issues
to consider:
- User organization. Subsystems may be organized along lines that mirror
the organization of functionality in the business organization (e.g. partitioning
occurs along departmental lines). This partitioning often occurs early in
the design because an existing enterprise model has a strongly organizationally
partitioned structure. This organization pattern usually affects only the
top few layers of application-specific services, and often disappears as the
design evolves.
- Partitioning along user organization lines can be a good starting point
for the model.
- The structure of the user organization is not stable over a long period
of time (due to business reorganization), and is not a good long-term
basis for system partitioning. The internal organization of the system
should enable the system to evolve and be maintained independently of
the organization of the business it supports.
- Areas of competence and/or skills. Subsystems may be organized to
partition responsibilities for parts of the model among different groups within
the development organization. Typically, this occurs in the middle and lower
layers of the system, and reflects the need for specialization in skills during
the development and support of complex infrastructural technology. Examples
of such technologies include network and distribution management, database
management, communication management, and process control, among others. Partitioning
along competence lines may also occur in upper layers, where special competency
in the problem domain is required to understand and support key business functionality;
examples include telecommunication call management, securities trading, insurance
claims processing, and air traffic control, to name a few.
- System distribution. Within any of the layers of the system, the
layers may be further partitioned "horizontally" to reflect the
physical distribution of functionality.
- Partitioning to reflect distribution can help to visualize the network
communication which will occur as the system executes.
- Partitioning to reflect distribution can, however, make the system more
difficult to change if the Deployment Model changes significantly.
- Secrecy areas. Some applications, especially those requiring special
security clearance to develop and/or support, require additional partitioning
along security access privilege lines. Software that control access to secrecy
areas must be developed and maintained by personnel with appropriate clearance.
If the number of persons with this background on the project is limited, the
functionality requiring special clearance must be partitioning into subsystems
that will be developed independently of other subsystems, with the interfaces
to the secrecy areas the only visible aspect of these subsystems.
- Variability areas. Functionality that is likely to be optional, and
thereby delivered only in some variants of the system, should be organized
into independent subsystems which are developed and delivered independently
of the mandatory functionality of the system.
| |
|