Design – Build – Run: Applied Practices and Principles for Production-Ready Software Development

14.8. Summary

This chapter looked at how the architecture from such a simple application can be broken down into multiple layers and moving parts. It also identified a whole host of potential components for the solution. I can't reiterate enough the messages in the earlier chapters regarding scope, budgets, and timescales. The previous chapter started off with a simple statement membership system. Through the process of extrapolation and extension, the component model has grown considerably (and it doesn't include base classes, web controls, stored procedures, tables, or views). The number of components gets even bigger if you start to add in unit tests, integration tests, stubs and simulators, configuration, and batch-execution frameworks. As the book progresses, you'll see that applying the patterns and practices to the solution will extend the scope even further. You started with some simple guiding principles, which have truly expanded, and created a good number of components.

The following are the key points to take away from this chapter:

• Have an architecture. You should always ensure that you have a solid architecture to build upon. Producing a conceptual architecture design helps to layer the solution appropriately.

• Keep the architecture modular. You should separate components into discrete layers and include frameworks that can add value. Although this increases the number of components, it simplifies the design of each layer and promotes reuse across the solution components. ...