The back end will be the more substantial part of the system. It does not matter if it loads many libraries or files: content changes far less often than it is accessed. See the appendix, “Putting dynamic content into perspective”.
The main organisational abstraction proposed for the back end is the component. A component retains the essence of MVC, like the initial example, but within a framework with additional layers. It has its own views and models and, when necessary, can access other components’ models, shared libraries and the loaded application.
Organising code into components is very useful when building complex, scalable systems.
Additional abstraction layers bring advantages, but may also require more code, files and general framework “bureaucracy” before work can begin. The more clearly the architecture is defined, the more rules and interfaces developers must follow.
Even so, in this context the advantages clearly outweigh the drawbacks:
• Each component behaves like a small application in its own right, following the environment’s rules while encapsulating its own functionality.
• Teamwork is supported because different team members can develop different components independently, extending the system in parallel.
• Components can have independent release cycles. The front end can be updated without affecting the back end, and individual components can be updated without destabilising the rest of the application.
• Focus is retained. If the business model is to develop a particular kind of software, customer requests need not turn the application into a succession of patches. Bespoke components can be developed, then enabled or disabled as required.
• Components can be reused. A bespoke system can be assembled by enabling or disabling components. Two customers’ needs may seem very different, but their technological and software solutions will share many features. The aim is to reuse comparable functionality that is not part of either customer’s core business model.
The preceding diagram summarises the proposed back-end architecture.
Compared with the initial MVC diagram, Application loads more functionality, libraries have been added, and components are organised as small MVC applications sharing an environment. They can interact: for example, the news component imports the sections model from another component. This approach offers the advantages already discussed.
