Hello,
I am new to FDD (almost finished reading the practical guide book), and I have a question regarding reuse and FDD. When I say reuse I mean reuse of problem domain (PD) code (not the other layers). FDD seems to have some ingredients (e.g. a domain modeling phase) that are in favor of introducing reuse in the picture. Also features perhaps can be mapped to familiar reusable artifacts (e.g. a feature area to a subsystem, a major feature set to a component, a feature to an interface or a method and so on). Of course research and experience is required for such a mapping to be made precise.
Are you aware of any work (e.g. academic papers, experience reports etc) in relation to FDD and reuse both for building reusable domain components or classes in the context of FDD and reusing domain components or classes in the context of FDD? or do you happen to have such experience from your own projects?
Thank you in advance
George
FDD and reuse
Wed, 10/21/2009 - 16:59 — george
- Login to post comments
User login
Random image
Syndicate
Reuse and Iterative Development
I find 'reuse' in software development to be something that everyone says is a good idea and should be done. Then I drill down and find that everyone has a different idea of what they mean by 'reuse'. Reuse of compiled code, source code, design (e.g. patterns), analysis, tests, people's experience and knowledge, etc, etc.
Having said that, there is inherent reuse in any iterative development approach, not just FDD. In each iteration we build on (reuse) the work we have done previously. When adding a new feature, a feature-team will reuse the classes and methods that already exist as much as it makes sense to do so. They will also add to and enhance existing classes as necessary.
One of the things I like about FDD in particular is the practice of class ownership, where each class is 'owned' by a specific developer. This ownership responsibility helps maintain the conceptual integrity of the class and it's public interface .. and that can only help keep a class as reusable as possible.
Obviously, when looking at the features required, if the team know of a component from outside the project (commercial, open-source, within an enterprise's 'reuse' library, similar work done in another project etc) that might fit, they are likely to evaluate it - they'd be immature not to.
If you are really asking, could a team that is tasked with building a centralized library of reusable domain components employ FDD as their process for doing so, then I personally do not see too much of a problem with that ... and the delivery of frequent, tangible, working results is likely to work better than a traditional waterfall approach.
If you are really asking, does FDD cover the identification, harvesting, indexing, promoting and maintenance of reusable components from a set of projects, then I personally would say, that while FDD does not explicitly cover that, there is nothing in FDD that actively precludes it.
Stephen R. Palmer
www.step-10.com
FDD and Reuse
Dear Stephen,
As you say iterative agile methods in general and FDD in particular, are attractive from a reuse perspective, because of the frequent delivery of tangible work products. These incremental delivery milestones provide points for accessing reusable code from previous products as well as (I think) opportunities for organizing your code, tests, designs etc. for reuse in future products as well as the next iteration. I am interested in exploring this interplay between agile methods and reuse, and I think that FDD is probably the best agile method for doing so, because of the “Develop an overall model” phase, the feature-centered development approach (DBF/BBF) and the individual class ownership concept.
Thank you for your reply
George
Reuse in Agile
I don't have experience with FDD, but a lot with XP. I find that reuse works just fine with that process. I actually find that collective code ownership is great for reuse, especially in combination with promiscuous pair programming and collocation. If you have questions, please inquire.
Reuse and Agile methods
Hi ipreuss,
Presumably collective ownership, pair programming and collocation help because everybody develops better knowledge of the code base. Are there any other reasons that these practices help towards reuse?
There is a distinction (made by Craig Larman in his book), between low-level business services (e.g. Currency Converter) and domain or business layer (e.g. POS, Inventory). What would you say that you mainly reuse of these two?
Do you mainly reuse classes, packages, or packages of packages (subsystems)?
Finally if I’m not two indiscreet, does your organization develop applications in many domains or mainly in one (e.g. financial domain) and how many developers are in your team?
Thanks again
George