A Component-Based Approach to Software Architecture
When we’re starting a software project, we never know all the requirements that the users will throw at us once they are actually using the software. A software project is always associated with taking chances and making educated guesses (we like to call them “assumptions” to make it sound more professional). The environment of a software project is just too volatile to know in advance how everything will play out. This volatility is why the Agile movement was born. Agile practices make organizations flexible enough to adapt to change.
But how can we create a software architecture that can cope with such an agile environment? If everything can change at any time, should we even bother with architecture?
Yes, we should. As discussed in Chapter 1, Maintainability, we should make sure that our software architecture enables maintainability. A maintainable code base can evolve over time, adapting to external...
