domain-driven-design - 重写软件时如何处理遗留数据完整性问题？

Question

我正在开发一个重写现有遗留软件的项目。旧版软件主要由 SQL 数据库上的 CRUD 操作(创建、读取、更新、删除)组成。

尽管是基于 CRUD 的编码风格，但遗留软件非常复杂。这种软件复杂性不仅是问题域本身复杂性的结果，也是糟糕(并且经常近乎疯狂)设计决策的结果。这种糟糕的编码导致数据库中的数据缺乏完整性。这些完整性问题不仅在关系(外键)方面，而且在单行内的完整性方面。例如，“x”列的含义与“y”列的含义完全矛盾。 (在您问之前，答案是"is"，我已经分析了问题域并正确理解了这些列的含义和目的，并且似乎比原来的软件开发人员更好)。

在编写替代软件时，我使用了域驱动设计和命令查询职责分离的原则，主要是由于域的复杂性。例如，我设计了聚合根以在写入模型中强制执行不变量，命令处理程序执行“交叉聚合”一致性检查，查询处理程序以适合各种屏幕的方式查询有意非规范化的数据等。

就准确性和易用性而言，替换软件在输入新数据时运行良好。在这方面，它是成功的。但是，由于现有数据充满了完整性问题，涉及到现有数据的操作经常会因抛出异常而失败。这通常是因为无法从存储库中读取聚合，因为传递给构造函数的数据违反了聚合的不变量。

我应该如何处理这些“违反规则”的遗留数据。旧软件在这方面运行良好，因为它几乎没有进行验证。由于缺乏验证，没有经验的用户很容易输入无意义的数据(而有经验的用户变得非常有值(value)，因为他们多年了解它的“特质”)。

数据本身很重要，不能丢弃。我能做些什么？我尝试在进行过程中解决完整性问题，这在某些情况下有效，但在其他情况下几乎是不可能的(例如，由于原始开发人员决定不保存数据，因此数据库中完全丢失了数据)。数据完整性问题的绝对数量是压倒性的。

我能做些什么？

Answer 1

对于带有 DDD 标记的问题，答案几乎总是与您的领域专家交谈。他们希望事情如何运作。

我还注意到您的问题带有 CQRS 标记。你真的在实现 CQRS 吗？在那种情况下，它应该几乎不是问题。

您的域模型将存在于应用程序的命令端并始终强制执行验证。读取堆栈将只提供哑 View 模型。这意味着在读取时，甚至不涉及您的域模型，也没有应用验证。它只会显示它可以用来填充您的 View 模型的任何废话。但是，在写入验证时会触发。并且任何写入都需要遵守您的 View 模型的完整验证。

现在回到现实:非常确定您实现的验证实际上是所需的验证。例如，即使是简单的电话号码(通常实现为 3 位破折号 3 位破折号 4 位数字)。但是后来公司有特殊的电话号码，比如1800-CALLME，不仅有数字，还有字母，甚至可以有不同的长度(不同的国家也可能有不同的规则)。如果您的系统需要处理此问题，这在很大程度上意味着您无法对电话号码应用任何验证。

这只是一个示例，您可能认为真正的验证实际上根本无法实现，因为它需要处理 1 个特殊情况。这里的规则又变成了。与您的领域专家交谈，他希望如何处理事情。但是要非常小心，您的验证不会使真实用户几乎不可能使用您的系统。因为这是杀死您的项目的最快方法。

更新:在 DDD 中，您还会听到术语反腐败层。该层确保传入的数据符合您的域模型的期望。这可能是首选方法，但如果您说您不能忽略带有垃圾数据的项目，那么这可能无法解决您的问题。