|
|
|
|
|
|
by vinceguidry
3428 days ago
|
|
|
> My single question to see if someone is practicing DDD is: do you refactor your codebase on deeper insights? I've been wanting to do this for a long time, I've devoted a lot of thought to working out when and how to perform these refactorings. But the reality is, business concerns drive the development of software, not the other way around. The big reason why refactoring is needed is technical debt, not because the vision of the project changes. You have to get the code clean and well-designed before you'll be able to easily have insights about it. It's all a team can do to chip away at the debt slowly over time barring a bunch of resources devoted to a big cleanup. In order to make insight-driven refactoring work, you first need to finish cleaning up your debt. Otherwise whenever you try to get started, the debt will get in your way and you'll start yak-shaving until another feature request or bug pops up. Debt cleanup never gets finished, so refactoring on the basis of insight never gets done either. |
|
|
In reality domain experts are not available (if existant at all). You implement features in shortest path possible and most of the time never really refactor. Gap between domain and implementation widens... and if you are lucky at one point decide on rewrite which only works if your devs became domain experts themselves.
My solution to that problem is to write software with tools which make refactoring cheap and it's kind of working for me.