域与数据持久层中的干净架构验证？
我正在研究干净的软件，因此，我极大地重新思考了如何设计和编写软件的大量方法。 不过，我仍在努力处理业务规则，例如“保存某些项目的更新，首先加载我有权查看/编辑的所有项目列表，确认该项目在列表中，并且该商品类别当前未被锁定（以及其他规则等）。”，因为这是（复杂但非典型的）业务规则，因此应在应用程序域中进行处理，而不是将业务逻辑推送到db / persistence层。 但是在我看来，为了有效地检查这些条件，通常最好使用精心设计的数据库查询来最好地处理它，而不是将所有数据加载到应用程序域中... 如果不进行过早的优化，有什么推荐的方法或鲍勃叔叔的文章处理这个问题？还是他会说“在域中进行验证，直到出现问题”？ 除了最基本的用例之外，我真的在努力寻找任何好的示例/样本。 更新： 大家好，谢谢您的答复。我应该更清楚一些，我已经写了很长时间（主要是Web应用程序）软件，并且肯定已经经历并同意您共同描述的所有主题（通过后端验证，一般不信任客户端数据仅在需要时才追求原始效率，但是在可用时承认db工具的优势，等等），并且已经经历了开发人员学习生命周期的“全部整合”以“构建具有N层应用程序的大型胖控制器”代码趋势，现在真的很喜欢研究干净/单一责任的样式等，这主要是由于最近有一些项目随着项目的发展以及对客户的进一步要求逐渐演变为笨拙且分布广泛的业务规则。 特别是，我在构建REST的API面向客户和内部使用功能的背景下，看着清新的风格建筑，其中许多业务规则可能是多比基本上你在网上看到每一个例子更复杂（甚至由Clean / Hex体系结构专家自己完成）。 所以我想我真的是在问（并且没有清楚地说出）Clean和REST api会如何放置在一起，这些天您看到的大多数MVC东西都带有传入的请求验证器（例如.NET中的FluentValidation库），但是其中许多我的“验证”规则不是“这是少于50个字符的字符串”，而是更多的，“如果某个相关对象当前已被Team X锁定，则该调用此用户案例/交互者的用户可以对数据集执行此操作吗？直到本月下旬，等等”。。。那些涉及深层次的验证，其中适用于业务域对象和域规则的数量。 我是否应该将这些规则分解为特定类型的Validator-object类型，以与每个用例交互器一起使用（受FluentValidator项目的启发，但涉及更多的业务逻辑和数据访问），我是否应该将验证视为类似于Gateway，我应该将那些验证放入网关（我认为这是错误的）等。 作为参考，我会去像几篇文章这样，但马蒂亚不讨论验证了。 但是我想我的问题的简短答案很像我接受的答案：“这绝非易事，要视情况而定”。