Layers
A software architecture identifies a set of rules for decomposition – the assumptions used to modularise a software system. A major aspect of the architecture is the identification of the different partitions into which you can put the various pieces of software that are going to be used to provide your solution to a problem. Any proposed change to a system will have a different impact, depending on the software architecture chosen. Here we look at three ways of decomposing an architecture, with layers, with components and with services.
Figure 2 illustrates one instance of a layered architecture that can be found in distributed computing systems. The top layer concentrates on the presentation aspects concerned with the user interface, which are more prone to change than the rest of a software system. (It is natural to expect a number of requests from users to make a software system more usable.)
The application domain is concerned with support for the way a user performs a given task, such as the processing of a customer’s order. A business may redesign the tasks that its employees perform, but perhaps not as often as amendments will be made to the user interface. Unless a business makes a radical shift in its core business concepts and transformations, the business services are less prone to change than the user interface.
The infrastructure contains the system support that usually includes the operating system and the databases, which allows the system to be more easily ported to new platforms.
Reuse is one strategy to deal with increased complexity of software and it addresses the concerns of maintainability, minimising costs, short delivery times and quality of software.