1

一些 DDD 书籍如[1]指出，虽然我们有一个领域模型，但我们可以有多个应用程序服务层（有些使用术语服务层）。这是因为应用程序层是应用程序的特定 UI 与域模型和基础设施层之间的接口，因此如果我们有多个与后端一起工作的用户界面，则可能存在多个应用程序服务层。这一点向我提出了应用层在哪里定位的问题。
我正在使用 .NET C# 创建一个应用程序。整个应用程序在一个解决方案中，其中 UI（我们有三个将使用后端的不同 winform 应用程序）是单独的项目，而后端项目（包含域层和基础设施层的类库）是一个单独的项目：

-- My Solution 
    |
    +-- Application.UI Number 1
    +-- Application.UI Number 2
    +-- Application.UI Number 3
    +-- Application.Backend
             |
             +-- Domain Layer (Model and Domain Services)
             +-- Infrastructure Layer (Repositories with ORM-Tool)

在示例中，到目前为止，我已经看到应用程序服务层位于Application.Backend. 但是，基于我们可以为每个 UI 拥有不同的应用程序服务层这一事实，这是正确的吗？你把项目放在Application.ApplicationLayer1哪里？还是将所有应用程序层合并为一个应用程序服务层？Application.ApplicationLayer2Application.ApplicationLayer3

埃斯波西托等人。[1]状态：

表示层和应用层是系统前端的一部分；

Application.UI他们在其中一个示例中添加了项目中的应用程序层。其他书籍如[2]在后端而不是前端有一个独特的应用程序层。
在 UI 中插入应用程序服务层让我很恼火。原因是应用服务层包含了应用的所有业务用例。它是领域模型和基础设施层的客户端。这意味着通过将应用程序层放在 UI 中，每个 UI 都会有自己的应用程序层。但是 UI-1 中使用的一些用例很有可能也在 UI-2 中使用。因此，您将有代码重复。

哪个是正确的？

4

1 回答 1

0

我确实将应用程序层视为域的唯一入口点。应用程序服务和/或事件处理程序可能存在于该层中。考虑到 Onion 架构，可视化各层，应用程序层包装了域之一。

很好，你挑战了它，但我认为你已经自己回答了。应用层应该是后端的一部分。

不过，我不会将服务与 UI 一对一地映射。我会按功能或资源将它们分开。如果不会产生大量开销，那么使用命令和视图驱动的应用程序服务进行额外的写入/读取分离可能也会很好。如果您的 UI 需要相同的数据但经过转换或丰富，您可能希望在中间的额外“转换”层中解决它，或者通过更灵活的查询接口（例如 GraphQL）来获取它们

这是我对此的看法。

于 2020-12-09T11:45:13.823 回答