Feature-Driven Development: An Agile Alternative to Extreme Programming


The Domain-Neutral Component (DNC) Pattern
When the different archetypes are put together according to these basic grammatical rules, a resulting structure is a domain neutral component. The domain-neutral component is a particular structural pattern of interactions between archetypes in a sentence that recur over and over again throughout all systems. It has a mostly symmetrical shape, and occurs at all levels of scale within a system (fractal-like in nature).

These domain-neutral components are the higher-level building blocks (components) of the system: they represent business flows and plug in to each other in predictable ways. They also embody a traceable and transparent mapping between features, designs, and code in an FDD project. When a particular instance of a domain-neutral component is created for a particular part of the system, it is sometimes called a domain specific component. Numerous kinds of domain specific components recur throughout many different products and programs within the same domain, and their essential essence may be catalogued and reused as a domain specific component patterns.

Domain specific components can themselves be connected to other such components in commonly recurring ways, and the result can be called a compound component. Each component takes on a characteristic shape and the commonly recurring object types and extension points.

The Java Modeling in Color with UML book defines 60+ enterprise component models and 10+ compound components representing patterns that can be used, extended, tailored, and applied to a variety of systems and domains. It should be noted that Color Modeling is not explicitly required in order to do FDD. There are, however, those who feel it is an implicit part of FDD as originally put forth by DeLuca Coad. They would liken doing FDD without consistently applying color modeling, to doing XP without consistently applying refactoring. The color modeling patterns impose a structure and semantics on the model that encapsulate and separate concerns, and isolate and insulate features for parallel work and integration. The resulting code often needs little or no significant refactoring (restructuring). See the following sources for more resources on color modeling:

• Wikipedia page on UML Colors
• Arguments about Color, by Daniel J. Vacanti
• UML Color Modeling with Archetypes

FDD is Football-Driven Development (and XP is Rugby)
When I first heard about FDD and saw an overview presentation, my initial reaction was that it didn't look very agile to me. Other than the fact that it used iterative development, everything else about it resembled more traditional plan-driven approaches with Waterfall/V-model phases, apparent elements of CMM, and formal ETVX-based process

About the author

Brad Appleton's picture Brad Appleton

Brad Appleton is a software CM/ALM solution architect and lean/agile development champion at a large telecommunications company. Currently he helps projects and teams adopt and apply lean/agile development and CM/ALM practices and tools. He is coauthor of the book Software Configuration Management Patterns, a columnist for the CMCrossroads and AgileConnection communities at Techwell.com,  and a former section editor for The C++ Report. You can read Brad's blog at blog.bradapp.net.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!