I've just started working on a project and we're using domain-driven design (as defined by Eric Evans in Domain-Driven Design: Tackling Complexity in the Heart of Software.  I believe that our project is certainly a candidate for this design pattern as Evans describes it in his book.I'm struggling with the idea of constantly refactoring.I know refactoring is a necessity in any project and will happen inevitably as the software changes.  However, in my experience, refactoring occurs when the needs of the development team change, not as understanding of the domain changes (refactoring to greater insight as Evans calls it).  I'm most concerned with breakthroughs in understanding of the domain model.  I understand making small changes, but what if a large change in the model is necessary?What's an effective way of convincing yourself (and others) you should refactor after you obtain a clearer domain model?  After all, refactoring to improve code organization or performance could be completely separate from how expressive in terms of the ubiquitous language code is. Sometimes it just seems like there's not enough time to refactor.Luckily, SCRUM lends it self to refactoring.  The iterative nature of SCRUM makes it easy to build a small piece and change and it.  But over time that piece will get larger and what if you have a breakthrough after that piece is so large that it will be too difficult to change?Has anyone worked on a project employing domain-driven design? If so, it would be great to get some insight on this one.  I'd especially like to hear some success stories, since DDD seems very difficult to get right.Thanks!
Refactoring in domain driven design
design patterns;architecture;object oriented;scrum;domain driven design
I've been a big fan of DDD for a while (with and without the safety net of a test framework). The whole concept and lifecycle of refactoring doesn't change because you're now using a new design methodology. If it will take significant time, it has to have proportional benefit to the project in order to get that time from management. With respect to doing it: in one instance, I partook in a 3 month major refactoring because of a 'breakthrough' in the understanding of the domain model. It required tests to verify the current behaviour, tests to verify the expected behaviour and changes to calling code. The benefits were significant however, and allowed the business to do many more things that it needed to do before but just wasn't able to. In essence, the refactoring was essentially a 'feature'. 