This page is intended to discuss the question
Is Domain Engineering compatible with Agile Software Development?
Given the current popularity of agile methodologies in the general software development community it is worthwhile to position
DomainEngineering appropriately in order to avoid being dismissed as an unworkable, high-ceremony approach. Highly automated software development and the principles of the agile alliance don't have to be exclusice. In practice I found that using model-driven generators naturally leads to agile
ApplicationEngineering?, opening up possibilities of domain exploration to application engineers that would be completely impractical in traditional, manually driven software development. Using advanced model-driven generators allows to react to most user requirements changes within hours and days rather than weeks or months, allows to shorten iteration times, and speeds up the user feedback cycle.
The mainstream attitude to generation is reflected in the otherwise excellent book
SurvivingObjectOrientedProjects? by
AlistairCockburn?:
... my colleages and I estimated that perhaps 5 percent of the total system code could have been generated from the business object model. ... The problem comes when you must add some computation that cannot be generated automatically. At that moment, the drawing of the object model, which moments before was an asset, becomes a liability ...
In short, the state-of-the-art of generative techniques is often judged by what is provided in the better known
UML tools such as Rose, Together, and others. Needless to say that this makes it harder to convince traditional development teams that there is something to be gained by
DomainEngineering and domain-specific techniques. To counter the simplistic arguments against generative techniques I have compared manual development, "traditional" development with a
UML tool, and model-driven development with a modern generator in
http://www.softmetaware.com/mda-implementationandmetrics.pdf. The comparison concentrates on the gains achievable by generation, and consciously relies largely on
UML-based notations, with only a few domain-specific elements.
DomainEngineering leads to agile
ApplicationEngineering?, but what about
DomainEngineering itself?
Does it make sense to talk about agile
DomainEngineering?
JornBettin
Agile
DomainEngineering requires a lot of flexibility from the tools that are used to build generators. I am aware of a few papers that address this issue, albeit in different terminology:
JoostVisser
In my feeling,
DomainEngineering has a strong big-design-upfront
feeling, which is at odds with, e.g.,
ExtremeProgramming.
Discussing this with Howard Goodell, we also observed that
- The explicit customer involvement of agile methods feels like a good combination with end-user programming as made possible by DomainSpecificLanguages
- XP talks about letting end-users do acceptance testing via a DomainSpecificLanguage
--
ArieVanDeursen