I currently have a client that wants me to ‘abstract’ out a domain model from the existing code but they specifically said that I shouldn’t refactor the existing code itself. My question is 1) whether or not this is advisable and 2) what techniques would you apply in this scenario if you can’t refactor the code yet they expect you to come up with a model for it?
(EDIT: I can’t quite put my finger on it, but somehow, not being able to refactor in this case just feels wrong. Has anyone else run into this type of scenario?)
This sounds to me almost impossible to achieve.
The only limited thing you could do that might meet what they want is to restructure your projects/assemblies to introduce proper heriarchies.
From what you describe, I’m imagining a big code base with everything in a single assembly, perhaps with business logic classes sitting alongside data access classes, maybe even so UI code if you are really unlucky.
From this you could introduce a (very poor) approximation of a domain model by moving all your business logic into its own assembly that references the data access logic.
Doing that, you would only need to change how classes are references and not change existing code. However you would not have a domain model… you’d have one assembly that kind of has domain logic within it.
Introducing a proper and useful domain model is impossible without refactoring. The whole point of the process is to identify the actual business entities that you are expressing and then reflect these entities in the domain model. That will require introducing new classes, extracting methods out, fiddling with your abstractions. (That just being the start of the process)
After seeing your comment, I thought it worth mentioning two approaches that explicitly deal with the problem of legacy code in an evolving code base.
Both other these approaches could help you move towards what the client is asking for. I’d still stand by my main answer – that you aren’t introducing a domain model, but this could be a first step of creating a useful domain model that does not require major rewrites of the legacy code.
The idea here is that you build your new application up over an existing application, much like a vine, slowly surrounding and then killing off parts of the original application as they are replaced.
It is very intentionally a slow process, reducing risk and making the gradual phasing out of the legacy system understandable.
There is a description of the Anti Corruption Layer here. The main idea is you create an interface over legacy code that manages is and shields your domain model from the complexity.