Layering represents an ordered grouping of functionality, with the application-specific functionality located in the
upper layers, functionality that spans application domains in the middle layers, and functionality specific to the
deployment environment at the lower layers.
The number and composition of layers is dependent upon the complexity of both the problem domain and the solution
space:
-
There is generally only a single application-specific layer.
-
Domains in which previous systems have been built, or in which large systems are composed in turn of
inter-operating smaller systems, have a strong need to share information between design teams. As a result, the
business-specific layer is likely to partially exist, and may be structured into several layers for clarity.
-
Solution spaces that are well-supported by middleware products, and in which complex system software plays a
greater part, have well-developed lower layers, with perhaps several layers of middleware and system software.
Subsystems should be organized into layers:
-
Application-specific subsystems are located in the upper layers of the architecture
-
Hardware and operating-specific subsystems are located in the lower layers of the architecture
-
General-purpose services occupy the middleware layers
The following is a sample architecture with four layers:
-
The top layer, the application layer, contains the application-specific services.
-
The next layer, the business-specific layer, contains business-specific components, used in several
applications.
-
The middleware layer contains components such as GUI-builders, interfaces to database management systems,
platform-independent operating system services, and OLE-components (such as spreadsheets and diagram editors).
-
The bottom layer, the system software layer, contains components such as operating systems, databases,
interfaces to specific hardware, and so on.
A layered structure starting at the most general level of functionality and growing towards more specific levels of
functionality.
|