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.


  • If you're writing code that you don't think you will ever be able to change regardless of size, stop.
    – JeffO
    Dec 20, 2010 at 1:29
  • @Jeff: It's not a matter of not being able to change it, it's a matter of the time and resources necessary for changing it increasing as code gets added. Dec 20, 2010 at 3:38
  • 2
    If you're adding code knowing the existing code needs refactoring and you don't, you're taking a risk. That doesn't mean it won't work.
    – JeffO
    Nov 18, 2011 at 14:08

4 Answers 4


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'.

  • Glad to hear you were successful at making such a large refactor. It's also good to hear you had to make such a big change to begin with. This is the kind of refactor I'm talking about. Months long with huge impact. Dec 20, 2010 at 3:38
  • Refactoring as a feature is one I'll remember. Jun 2, 2011 at 19:03

Refactoring in Domain Driven Design is I think driven from a need, not a "nice" refactor. As soon as you identify an incorrect Domain Model, the code/system is not representing the real world problem.

Case in point, we recently worked on an application of reasonable domain complexity. It was a Billing/Contract system, and we were introducing a new type of rate. We were using an agile process, 2 week scrums to be precise.

Initially we identified in the model the 2 rates were completely seperate and had no relation except through the Contract. However as we completed more stories, we came to the realisation that they actually were the same, especially when we started to wrap the new rate as an old one just to get it to work. This was the first warning sign.

To cut the story short, we were able to get 90% of the stories done with the incorrect model, but we got to the point where in every part of the code we were either wrapping the new Rate as an old one, and/or creating if newRate else oldRate EVERY where. We were banging our heads against the proverbial brickwall. We were half way through this part of the project, and knew the time to complete will be exponential or unworkable with the incorrect domain model. So we bit the bullet, split a story to eight other stories and refactorer the Domain Model.

When we completed the project, we knew from hindsight it was the right thing to do, and was the ONLY thing to do to get it right.

Did it take time? Yes, but if we didn't do it, it would have taken more time. Was it DDD done right? Well, funnily enough we didn't know about DDD at the time, but soon after we attended a DDD workshop by Eric Evans, and all me and my colleagues could do is nod the way through. I think if we knew DDD, we would've picked up the refactor much earlier thereby saving more time.

  • Great answer. We go through something similar to this every few months. Glad to know we're not alone! Mar 6, 2011 at 14:28

If you get something wrong in the Domain Model its important to correct it. In my experience we missed a bit in how the domain model connects to it's different entities when we implemented some of it.

What this resulted in was that people used to model in ways it wasn't inteded for and thus breaks other parts of the model to try to "get it to work".

As soon as you realise that there is something wrong in the domain model, change it as fast as possible. The longer it takes before you refactor it the harder it will be to change with respect to the users, whos mental models now are adapted.


For some portions of the code, continuous refactoring is overkill. For some other portion of the code (in DDD, the so called Core Domain) is a necessity. Understanding that the code is not how it should be places an extra cognitive load on the developer (the difference between our understanding of the domain and the current implementation) that will make further evolutions more difficult and/or expensive.

The question is: "will these evolution be needed?". In the Core Domain (the area that is making a business difference) the answer is "Yes!". Because that's the potion of the domain the business is more concerned about and the one that will make a difference for the stakeholders. That's the place where you want to keep your code in perfect shape, ready to implement the next requirement with minimal effort, due to the flexibility of your Domain Model.

However that's going to be expensive when applied to all the application code. Areas which are not that significant for the business (Supporting or Generic Subdomains in DDD lingo) might require a less sophisticated approach than the one reserved for the core.

Not the answer you're looking for? Browse other questions tagged or ask your own question.