domain-driven-design - 服务层验证与域对象验证；域对象的潜在 "abuse"？

Question

我看过很多书和文章的例子都说要把验证代码放在你的服务层。保持域对象“哑巴”(又名，纯 POCO)并处理域对象可能在服务层执行的所有验证。

服务层似乎负责(或至少可以负责)；用户身份验证、角色身份验证、IoC 的脚本依赖对象(记录器、错误处理程序等)、脚本域对象、脚本存储库以及将域对象传入和传出存储库……哇!

在服务层创建所有这些规则不会对您的域对象构成重大威胁吗？例如，一些程序员决定直接针对您的领域对象编写消费代码并且完全绕过服务层，会发生什么情况？那会很糟糕，但这是一个可信的情况。

如果您要将很多职责放在服务层，包括所有域对象验证，是否有办法“保护”您的域对象，是否有人试图直接编写它们的脚本？例如，也许你的领域对象现在没有被某个客户端使用(在这种情况下，服务层？)。

好的设计让我觉得域对象应该对谁在调用它们以及它们是如何被调用一无所知。

如果没有办法“锁定”域对象，那么为什么有这么多文章、书籍等建议将域对象验证放在服务层中呢？我想通过采取防御性编程的立场，您应该构建防弹的域对象，并依靠您的服务层作为简单的代码层在 UI 和 BAL/DAL 之间转发和接收请求。

有没有人有过绕过服务层的人“滥用”他们的领域对象的真实项目经验？

Answer 1

我认为您可能误解了 POCO 的目的。据我所知，POCO 不是只有属性和属性的贫血域对象。相反，POCO 并不依赖于框架或复杂的继承模型。对象是灵活的，只关心它在域中的角色。