我正在尝试使用分层模式和DDD。但是我找不到应该在哪里加载用于在单个模型实体的编辑视图中填充组合框和列表框的目录。我是否应该在应用程序服务层中创建单个方法，以便在视图模型包装器中获取单个视图所需的所有列表？还是我应该为每个我需要的列表创建一个方法？或者它根本不属于服务层？
从表示层访问数据有两种主要策略，它们都有其优点和缺点。 总结一下：
1. 使用应用服务层。
应用程序服务层充当以下层的表示层的 API。这意味着应用程序服务是边界对象。您仍可以通过应用程序服务公开实体和值对象，但服务和存储库对表示层保持完全隐藏。
优点：
- 在层之间创建明确的分离，这使得代码更容易开发、重构、维护和测试，尤其是在团队中或与多个团队一起工作时。
- 如果需要在应用程序之上构建任何其他演示文稿，则您已经有一个 API 来构建它。
- 您可以在一个位置将表示逻辑与应用程序逻辑分开。
缺点：
- 添加了接线代码。您必须使用委派几乎所有工作的方法生成大量服务。当你做对了，就是这种情况。当你弄错了，你最终会得到一个贫乏的领域模型和一个肥胖的应用程序服务。
- 几乎不可能生成一个合适的 API 来服务于您还不知道的目的。服务调用的正确粒度只能通过其使用来确定。因此，如果您只有一个演示文稿，则您的应用程序服务无需更改即可重用是一种错觉。
我看到的一个子策略是应用程序服务和域服务都在表示层中使用，例如，请参阅本文。虽然我同意作者的立场，即应用程序服务和领域服务是根本不同的，但我不同意两者都应该在表示层内使用。当应用程序服务充当边界时，最好达到具有应用程序层的目的。这确实增加了接线代码的数量，但使以后添加应用程序逻辑变得更加容易。因此，我认为，如果你选择这种策略，你就会一路走下去。
2. 直接使用域层。
您只需从表示层中调用存储库和/或服务即可。
优点：
- 更少的接线代码。可以更轻松地查看小型代码库中的确切情况。
- 你的领域模型将在更多的地方使用，使其更能抵抗外部影响（如果你是一个好的程序员，随着时间的推移，事情会变得更好，而不是更糟）。
缺点：
- 纯应用程序逻辑将最终出现在表示层中。如果需要添加另一个演示文稿，您将不得不复制该逻辑或恢复到第一战术。
- 由于域模型可能提供多种实现相同目标的方法，因此存在逻辑重复的风险。重复代码容易检测也很难防止，重复逻辑很难检测，也很难预防。
我在野外看到的另一个子策略是域服务充当表示层的边界对象。因此，表示层无法访问存储库。我称之为反模式，因为应用程序逻辑、存储库逻辑和域逻辑显然是不同类型的逻辑（对某些人来说，这并不那么清楚）。如果域服务需要满足表示层的所有需求，则域服务将成为存储库的委托（坏），应用程序逻辑将最终出现在表示层中（可能是可以接受的），或者/和应用程序逻辑将最终出现在域服务中（坏）。DDD 中的域服务从不表示边界对象，而只是作为与域概念相关的操作容器，这些域概念不是实体或值对象的自然组成部分。因此，我再次认为，如果你选择这种策略，你就会一路走下去。
㯱
我希望我已经减少了这个相当复杂和多方面的讨论，以便您可以选择最适合您使用的策略。软件行业对这些事情没有明确的共识。我通常为保证长寿或有多个演示文稿的软件选择第一种策略，而对于未来仍然有些不确定且只有一个演示文稿的软件，我选择第二种策略。