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, there is 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 will have well-developed lower layers, with perhaps several layers of middleware
and system software.
Subsystems should be organized into layers with application-specific subsystems located in the upper layers
of the architecture, hardware and operating-specific subsystems located in the lower layers of the
architecture, and general-purpose services occupying the middleware layers.
The following is a sample architecture with four layers:
-
The top layer, application layer, contains the application specific services.
-
The next layer, 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, 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.
|