我正在开发一个重写现有遗留软件的项目。遗留软件主要包括SQL数据库上的CRUD操作（创建，读取，更新，删除）。
尽管基于CRUD的编码风格，传统软件仍然非常复杂。这种软件复杂性不仅是问题域本身的复杂性的结果，而且也是不良（并且经常接近疯狂）设计决策的结果。这种糟糕的编码导致数据库中的数据缺乏完整性。这些完整性问题不仅仅是关系（外键），还包括单行内的完整性。例如，列＆＃34; x＆＃34;的含义直接与列＃34; y＆＃34;的含义相矛盾。 （在您提出问题之前，答案是＆＃34;是＆＃34;，我已经分析了问题域并正确理解了这些列的含义和目的，并且比原来的软件开发人员更好）。
在编写替换软件时，我使用了Domain Driven Design和Command Query Reponsibility Segregation的原则，主要是由于域的复杂性。例如，我设计了聚合根以在写模型中强制执行不变量，命令处理程序执行＆＃34;交叉聚合＆＃34;一致性检查，查询处理程序以适合各种屏幕等的方式查询故意非规范化数据等。
在准确性和易用性方面，替换软件在输入新数据时效果很好。在这方面，它是成功的。但是，由于现有数据充满了完整性问题，因此抛出异常会导致涉及现有数据的操作失败。这通常是因为无法从存储库中读取聚合，因为传递给构造函数的数据违反了聚合的不变量。
我应该如何处理这些违反规则的遗留数据＆＃34;。旧软件在这方面运行良好，因为它在没有验证的情况下执行。由于缺乏验证，没有经验的用户很容易输入无意义的数据（而且有经验的用户因为多年来了解它而非常有价值，因为他们已经多年来了解了这些数据的特殊情况＆＃34; ）。
数据本身非常重要，因此不能丢弃。我能做什么？我一直在尝试整理完整性问题，这在某些情况下有效，但在其他情况下几乎不可能（例如，数据完全从数据库中丢失，因为原始开发人员决定不保存它） 。数据完整性问题的绝对数量是压倒性的。
我该怎么办？
答案 0 :(得分：0)
对于使用DDD标记的问题，答案几乎总是与您的域专家交谈。他们如何让事情发挥作用。
我也注意到您的问题标有CQRS。你实际上是在实施CQRS吗？在这种情况下，它应该几乎不是问题。
您的域模型将存在于应用程序的命令端，并始终强制执行验证。读取堆栈将提供愚蠢的视图模型。这意味着在阅读时，您的域模型甚至不涉及，也不会应用验证。它只会显示它可用于填充viewmodel的任何废话。但是在写入验证时会触发。任何写入都需要附加到您的viewmodel的完整验证。
现在回到现实：非常确定您实施的验证实际上是所需的验证。例如，即使是简单的电话号码（通常实现为3位数字，3位数字，4位数字）。但是公司除了像1800-CALLME这样的特殊电话号码，不仅有数字而且还有字母，甚至可能有不同的长度（不同的国家也可能有不同的规则）。如果你的系统需要处理这个问题，那么很多就意味着你无法对语音管理器进行任何验证。
这只是一个例子，你可能认为真正的验证真的无法实现，因为它需要处理一个特殊情况。这里的规则再次成为现实。与您的领域专家讨论他希望如何处理事情。但要非常小心，您的验证会使真实用户几乎无法使用您的系统。因为这是让你的项目被杀的最快方法。
更新：在DDD中，您还会听到反腐败一词。该层可确保数据符合您的域模型的期望。这可能是首选方法，但如果你说你不能忽略带有垃圾数据的项目，那么这可能无法解决你的问题。