Domain driven design 服务层验证与域对象验证；潜在的；“虐待”；域对象的定义？

我看过很多书和文章中的例子，说要把验证代码放在服务层中。使域对象保持“哑”（也称为纯POCO），并处理域对象在服务层中可能进行的所有验证

服务层似乎负责（或者至少可以负责）这么多事情；用户身份验证、角色身份验证、为IoC的依赖对象（记录器、错误处理程序等）编写脚本、为域对象编写脚本、为存储库编写脚本以及在存储库之间传递域对象。。。唷

在服务层中创建所有这些规则不会对您的域对象造成实质性的威胁吗？例如，一些程序员决定直接针对您的域对象编写消费代码，而完全绕过服务层？这可能很糟糕，但情况是可信的

如果您打算在服务层中承担很多责任，包括所有域对象验证，那么如果有人试图直接编写域对象的脚本，是否有办法“保护”您的域对象？例如，也许在某种程度上，您的域对象现在没有被某个客户端（在本例中是服务层？）使用

好的设计让我认为域对象不应该知道谁在调用它们以及如何调用它们

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

---

有没有人有过一些真实的项目经验，从绕过服务层的人那里“滥用”他们的域对象？

他们是两种不同的设计理念。富域模型与贫血域模型

简单的回答是肯定的，您可以阻止对域对象的直接访问

您可以使用多种技术来实现这一点：

1） 您可以使所有面向公共的域对象不可变（即，您不能更改数据），只需将唯一的公共方法作为getter即可。所有修改对象的方法都可以被保护或打包为私有，因此只有正确打包的服务才能访问它们（至少在Java中）
2） 您只能向外部开发人员公开单独的类——因此，如果您有一个Person域类，您可以拥有一个您放弃的PersonInfo类，该类只包含信息。

---

3） 您应该向应用程序消费者公开一致的API。您基本上可以防止它们绕过您的服务层。

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

#2听起来很像数据传输对象，我想？我想我可以使用DTO，或者可能返回一个只公开我认为最终消费者应该能够设置/获取的属性的接口？我将尝试一些不同的方法。我希望避免DTO，因为它们会给项目增加另一层复杂性。谢谢你的回复@indiecodemonkey，是的。但关键是有办法锁定api。同意Joshua的观点。贫血区域模型被认为是一种反模式，原因很多。从那个人身上，