Aspect-Oriented Programming: Road to a Resilient Architecture
This chapter is from the book
This chapter is from the book
This chapter is from the book
The single most important determinant of the quality of a software system is its architecture. A good architecture keeps concerns of different kinds separate so that a change in one does not affect other parts of the system. You establish this architecture by identifying the critical use cases for the system. By analyzing these critical use cases, you can build a resilient structure—one in which concerns of different kinds are kept separate and changes in one part of the system have minimum impact on the rest of the system. The architecture must also be designed to meet system-level concerns such as performance and reliability. The architecture is manifested in an early and critical version of the system, a version that can be made executable—a version we call the architecture baseline. It might take several iterations before you finally establish the architecture baseline, but when you do, you have validated your assumptions, your approach to developing the system, and you have reduced your risks. Based on this architecture, the rest of the development can speed up tremendously.
11.1 What Is Architecture?
Architecture clearly is important, but if you ask five different people what architecture really is, you will probably get five different answers. Architecture, like many other words, is something you cannot really touch. It is in that sense similar to process, use case, project, component. However, these terms are concrete in the form of their descriptions. We can understand a process description, a component description, a use case specification, a project plan and, thus, an architecture description. So, when we talk about architecture, we talk about how we understand the architecture description. Architecture is thus the semantics of an architecture description, which encompasses the major decisions about the system, such as:
- How are the system elements organized?
- How does the system realize the required functionality?
- How does the system meet the desired performance, reliability, and other quality characteristics?
- What technologies does the system require (e.g., Web client, rich client, a particular messaging middleware)?
- Are the internals of the system structured to be resilient to changes in functionality, technology, platform, and so on?
- Are standards in place to ensure that the system is developed consistently? For example, what design patterns will be used? What guidelines will be used to handle exceptions?
Definitely, there are important, project-specific decisions to consider. For example, you may have to interface to a particular legacy system. Or maybe the system has to be configurable and you need a way to define system parameters. Perhaps the system has to be remotely installed and managed. Possibly the system is to deal with the complexities of a particular business domain. The list goes on. But the architecture is not everything. It is just the top 20 percent of the most important things about the system.