I was looking yesterday at Eric Evans’ talk at the Øredev conference last
You really should see it to understand better one of the most important part of the DDD book that is
difficult to grasp on first reading.
I’m currently working on a small company that had a problem with scaling
their system. The existing system was working correctly but was going to stall
in both performance and evolution perspectives.
When we arrived, the plan of the preceding head of development was :
‘We need to restart from scratch, let’s specify everything, then code a
clean version 2.0 in two years, and switch the legacy system off.’
Of course it was expected to fail.
And even if it succeeded, after two years, they would have got the same
software that two years before.
It could be cleaner, but who cares ?
When you’ve lost two precious evolution years, for a promising startup,
count it as dog years.
When we took control of the situation we planned the following :
- Extract the core business value of the software.
- Spot where you need new features.
- Develop new features as if it was in a clean environment.
- Develop anti corruption layers to hide the legacy system behind clean
This way you start to work on new business value now, you
make the model cleaner over time, and you have benefits of the working legacy
Don’t waste your time recoding what is already working.
Act to add value to your business.This is where your craft should