关于使用DDD模型构建架构的问题

Question

我正在研究领域驱动设计并构建一个具有 4 层的解决方案（使用 C#、.NET 8）：表示层、应用程序、域和基础设施。我对如何继续实施有一些疑问：

1. 我在一些示例中看到应用程序、域和基础设施接口都集中在域层。但是，当我构建项目时，我想知道在各自的层中放置一个界面是否更有组织性。例如：

   UserApplicationService

   有

   IUserApplicationService

   。我可以将

   IUserApplicationService

   放在应用程序层还是必须放在域层？

2. 我正在使用 Dapper 通过存储库从基础设施层的 SQL Server 获取数据。我必须获得所有活跃用户，因此，在我的

   UserRepo

   中有：

   select * from user where active = 1

   。但是，获得活跃用户是一条商业规则。所以我有两个选择：维护带有 where 子句的选择或获取所有用户并在域层中过滤它们。如果我选择第一个选项，我就没有遵循DDD的原则吗？ （因为获取活跃用户的规则是在基础设施层）。但如果我选择第二个选项，并且我有 1,000,000 个客户端，我将损失性能。在这种情况下该如何进行？此示例的最佳解决方案是什么？

3. 我有一个工人服务项目。他必须位于表示层，因为是一个启动项目，或者位于应用程序层，因为没有用户输入，只是操作域层服务接收到的数据？

Answer 1

1. 应用接口应该放在应用层。它们是您的应用程序的合同，而不是您的域。
2. 你的存储库方法是有意义的。例如，在您的情况下为 GetAllActiveUsers() 。因此该方法的实现必须返回有意义的结果。因此，您的存储库实现有责任返回有意义的结果，并且逻辑就在那里。 注意，不建议获取活动用户列表来修改它们。在所有用例中，您应该只修改聚合的一个实例。但如果它是用于查询目的，可能没问题（也许它属于域服务而不是存储库）。
3. 可以在应用层。有些人会将应用程序层作为他们的 Web API。但你必须自己决定。您是否有一些会污染您的应用程序层的表示问题？我将这两者分开以符合关注点分离的要求。另一件需要考虑的事情是可重用性。如果将它们分开，您可以重用应用程序层用例。