领域驱动设计中的重构

Question

我刚刚开始做一个项目，我们使用的是域驱动的设计(正如Evans在领域驱动设计:解决软件核心的复杂性中定义的那样)。我相信，正如Evans在他的书中所描述的那样，我们的项目肯定是这种设计模式的候选者。

我一直在纠结于不断重构的想法。

我知道重构在任何项目中都是必要的，并且不可避免地会随着软件的变化而发生。然而，在我的经验中，重构是在开发团队的需求发生变化时发生的，而不是因为对域的理解发生了变化(正如Evans所称的“重构到更大的洞察力”)。我最关心的是在理解领域模型方面的突破。我理解做一些小的改变，但是如果有必要对模型进行大的修改呢？

什么是说服你自己(和别人)的有效方法，在你获得一个更清晰的领域模型之后，你应该重构？毕竟，为了改进代码组织或性能而进行的重构可以完全独立于普遍存在的语言代码的表达方式。有时候，似乎没有足够的时间进行重构。

幸运的是，SCRUM将自己借给了重构。SCRUM的迭代特性使得构建一个小块并进行更改变得非常容易。但随着时间的推移，这部分会变得更大，如果你有一个突破后，该部分是如此大，它将是太难改变？

是否有人参与过使用领域驱动设计的项目？如果是这样的话，我很高兴能对这件事有所了解。我特别想听听一些成功的故事，因为DDD似乎很难搞清楚。

谢谢!

Answer 1

有一段时间，我一直是DDD的忠实粉丝(不管有没有测试框架的安全网)。

重构的整个概念和生命周期并没有改变，因为您现在正在使用一种新的设计方法。如果要花费大量的时间，就必须对项目有一定的好处，才能从管理层那里得到这些时间。

在其中一个例子中，我参加了为期3个月的重大重构，因为在对域模型的理解上取得了“突破”。它需要验证当前行为的测试、验证预期行为的测试以及调用代码的更改。然而，这些好处是重要的，让企业能够做更多之前需要做的事情，但却无法做到。从本质上讲，重构本质上是一个“特性”。

Answer 2

在领域驱动设计中的重构是我认为是出于需求的，而不是“好的”重构。一旦识别出不正确的域模型，代码/系统就不代表现实世界的问题。

例如，我们最近研究了一个合理域复杂度的应用程序。这是一种收费/合同制度，我们正在引进一种新的费率。我们使用的是一个敏捷的过程，准确地说是2周的scrums。

最初，我们在模型中确定了这两个比率是完全分开的，除了通过合同，没有任何关系。然而，当我们完成更多的故事时，我们开始意识到它们实际上是一样的，特别是当我们开始把新的利率包装成旧的，只是为了让它开始工作的时候。这是第一个警告信号。

简而言之，我们能够用不正确的模型完成90%的故事，但是我们到了这样的程度:在代码的每一部分中，我们要么将新的速率包装成旧的速率，要么创建if newRate else oldRate。我们的头撞在众所周知的砖墙上。我们已经完成了这个项目的一半，并且知道在不正确的领域模型下完成的时间是指数的，或者是不可行的。所以我们咬紧牙关，把一个故事分成另外八个故事，然后重构领域模型。

当我们完成这个项目时，我们事后就知道这是正确的事情，也是唯一能使它正确的事情。

需要时间吗？是的，但如果我们不这么做，那就需要更多的时间。做得对吗？有趣的是，当时我们还不知道DDD，但很快我们就参加了埃里克·埃文斯的DDD研讨会，我和我的同事们所能做的就是点点头。我认为，如果我们知道DDD，我们会更早地获得重构，从而节省更多的时间。

Answer 3

如果您在域模型中出现了错误，那么纠正它是很重要的。根据我的经验，在实现某些域模型时，我们忽略了域模型与其不同实体的连接方式。

这导致了人们习惯于以模型的方式建模，而模型的其他部分则被打破，试图“让它发挥作用”。

一旦你意识到领域模型有问题，尽快改变它。重构前所需的时间越长，就越难对用户进行更改，谁的心理模型现在已经适应了。