How far can we go into the writing of an application without losing momentum?
As an application becomes richer, it typically becomes more complex. There are two aspects to this:
- Logical complexity increases as a result of new functionality binding to existing functionality.
- Physical complexity increases as a result of increased application size.
The result of increasing complexity is that developers find it increasingly challenging to add new features to an application. This complexity manifests itself in two ways:
- Your workspace is increasingly cluttered with irrelevant entities – entities that do not contribute to the feature you are developing
- Your code is increasingly dependant on existing elements of functionality.
Very large applications are typically broken down into modules. Modules reduce logical complexity by providing narrowing interfaces; physical complexity is reduced by keeping all the code for a given module separate from the code for other modules.
Feature architectures enforce micro-modularity:
- Each feature typically maps a single value increment or story.
- Features are abstracted from each other using channeled notifications.
Why design feature architectures?
Feature architectures are derived from story driven development. In agile, story driven development, developers collaborate towards the development of a given story cutting across the layers of a selected framework. Agile ensures that developers deliver value faster; in suitable contexts (assuming that value can be delivered incrementally), this maximises profitability while reducing the risk to produce large amounts of unused functionality.
Feature architectures take advantage of the separation between source spaces and runtime spaces to allow developing well formed (layered) runtime architectures while limiting linearly growing physical and logical complexity. This allows developers to focus on delivering atomic value increments without incurring mounting familiarization costs and splitting development across framework layers. Also, this may allow fairly large developer teams to collaborate without facing large communication costs.
In a nutshell, feature architectures and micro-modularity target value driven separation. In contrast, existing separation strategies and meta-patterns provide abstract roles that can be re-instantiated in a variety of contexts (the MVC meta-pattern is an example). This affords industry endorsement for high level design solutions. Beyond, classic separation models emphasize a component drive approach. While this means that component cores can be developed in parallel, this may result in glossing over communication interfaces between components.
Layered, component oriented architectures emphasize potential and structural integrity and are more suitable for long term investments and library development. Feature architectures emphasize value increments and may be ideal for writing application front ends:
- Reusable data and view components are already available
- Applications are feature rich, yet do not involve much complex code.
- Value increments typically involve cutting across layered architectures.
Working using a feature architecture
Feature architectures require developers to package features separately. Each feature is developed as an integrated micro-module – if you are writing an application, a feature will probably bundle view, model and controller functionality.
- Each developer or pair are responsible for designing and implementing a feature derived from a user story.
- The core functionality involved in developing a feature is developed independently from other features.
- The source code related to a given feature is bundled within a separate package.
- Developers integrate their feature by implementing handlers for channeled notifications.
- Developers expose required resources by providing external notifications.
- All source code for a given feature may be removed without causing the application to break at compile time.
Mmh… this may not be the best introduction to feature architectures I could write. I’ll try to improve on that and will also provide an application template very soon.
