Even in an agile world, specifications often go too far and describe solutions with too much details; all these premature decisions constraint the implementation and remove opportunities. There is a remedy: refactoring the specs, even before refactoring the code. In the TDD cycle, refactoring is the art of restructuring the code to make it simpler, without changing its behavior at runtime. A key part of refactoring is to recognize and extract duplications.
Refactoring is very useful at the code level, and it is even more powerful when applied during business analysis or functional architecture. We will show how the practice of refactoring directly “at the business domain level” can simplify the problem, and therefore the resulting implementation code, by orders of magnitude. This means much less code to write, to test and to maintain, and much less defects as a result.
We will introduce 5 patterns on how to refactor at the business-domain level, such as “Make It Systematic” and “Degenerate Case”. We will also explain some limits and the required mindset. This approach of refactoring has been used on several real-world projects and is derived in particular from DDD and from Specification by Example.
Watch this video on http://oredev.org/2013/wed-fri-conference/refactor-your-specs