Section 30.3. System Architecture

30.3. System Architecture

Emily gave a quick rundown of the architecture of the system, with brief sketches on the whiteboard. "The application is sort of structured as a three-layer system,^[1] but not quite," she admitted. "Yes, we know there's business logic tied up with GUI code, but it's difficult to change it. We're behind in development and fixing bugs, so it's difficult to find time to tidy things up."

^[1] See the Note on 257.

"But," added Neo, "we do need to separate the UI layer in order to introduce RentEz as a Web application. Or else duplicate the business logic code further. Neither approach is satisfactory."

"One reason for the problem," Emily suggested, "is that the GUI-building tools encourage development from the GUI, and that leads some of the programmers to include the business logic directly within the event-handling code. Another reason is that some of the programmers haven't got the point of having cleanly separated layers."

"Part of that," Neo added, "is that some of the business logic is closely related to the way the GUI works, such as which user interface operations can be carried out in a particular state of a client transaction."

"There's also a problem with the persistence layer," said Emily. "The database layer is not separated from the domain layer. We have SQL mixed up with the business logic. Luckily, that's not such an issue in the move to a Web application. But it causes problems when we have to make changes to the database schema or change the class structures."

"And when we need to improve database performance," added Neo.

Note

The Three-Layer Architecture [Fow02a] defines a layering to provide an important source of modularity. Ideally, it consists of three layers, as shown in Figure 30.1.

Figure 30.1. Three Layers

• The middle, domain, layer contains all the domain objects and the business logic and is independent of the particular user interface(s) that provide access to the user, as well as of the storage layer beneath it.

  This means that the top and bottom layers can be replaced or extended with minimal change to the middle layer. For example, with this approach, it is straightforward to add other types of user interfaces, as well as tests, in the top layer, as shown in Figure 30.2.

  Figure 30.2. Several Presentation Layers

  

  
  

  The classes and pubic methods of this layer are often referred to as the API (application program interface) of the application.

• The top, presentation, layer provides the user interface. Objects in the user interface layer access objects in the domain layer, calling methods in the domain objects when the user carries out operations on the user interface. User interface objects also registeranonymously, as listenersfor changes with domain objects, so that the state of the user interface can be changed when the corresponding domain objects change. This layer provides a mapping between the objects in the domain and the user interface.

  The interaction between these two layers can be described in terms of the Model-View-Controller model or MVC [Fow02a] in which the Model is an object in the domain object layer and the View and Controller are in the user interface layer. Because of the MVC model, the middle layer is sometimes called the model layer.

• The bottom, data source, layer provides for persistence: storage of data, usually to files or a relational database system. This layer needs to load objects from the data store, update them when they change, and communicate to the middle layer any changes to the data store caused from elsewhere.

  This layer provides a mapping between the objects in the domain and the underlying data store. A range of tools is available to automate much of this mapping for relational databases.

These issues are common in software development, as all the development effort goes into adding functionality and fixing bugs. Little or no time is put into structuring the software to manage change. It is not until the software gets larger and/or more complex that the need for flexibiity of the software is appreciated, by which time a lot of effort may be needed to rectify the problem. What's worse, time is rarely available to restructure for change, as so much time is spent on fighting the consequences of poor structure.