Abstract
This blog covers my own experiences of architecting within an Agile project. It assumes you have knowledge of an Agile process such as Scrum and have knowledge Lean engineering practices.
The blog is split into five parts:
Conceptual design and decision making
At some point early on in the sprint lifecycle you will come to realize that the Agile approach has to meet some old fashioned architectural design thinking. This has to be most forgotten part of working with Agile. Agile does not mean that everything you learnt about good design and object orientated principles are forgotten. If fact they are just as relevant as they always were. Practically, how you develop software is exactly the same, but how you break the solution down has changed.
For feature driven development to be successful, you must come up with a common design for the set of features you are working on. This is paramount to solving a common issue in Agile: rewriting code.
Rewriting of code occurs when you do not have knowledge of the complete set of requirements for a set of features. A set of features is what you should have conceptually bottomed out during envisioning the project. In a set of features, you are able to ignore features outside of this set without causing significant risk to the whole design of the solution. Sets of features correlate very well with well designed application services. In other words, this means extracting out services that can operate in a black boxed manner (operating entirely on their own).
Doing a design for a set of features involves concerning you and your team with the interface rather than implementation. Does this sound familiar? It should do, because the common OO principles of encapsulation, extraction and polymorphism are still the most important things you are working with. For feature driven development, designing the contract is still a key activity.