3

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

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

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

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

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

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

我能做些什么？

4

1 回答 1

0

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

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

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

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

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

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

于 2016-05-14T13:30:00.253 回答