Java 洋葱架构：UI项目是否应该访问域层？

我在看洋葱架构派，我很困惑

UI客户端是否应该访问

域模型

和

域服务

？还是仅限于

应用程序服务

和

核心

---

确切地说，我在问：UI项目是否应该引用域项目？

当然，我不认为有什么好的理由可以避免UI层了解和使用域对象。很明显，如果您这样做，您就是在将UI层耦合到业务层，但最终，UI层不依赖于业务吗

另一方面，相反的情况是不可取的，将业务耦合到UI层是不好的做法。如果您想让多个UI层访问相同的业务，该怎么办？这就是重点

---

但请记住，没有金锤。不要寻找关于软件设计的明确规则，而是学习坚实的原则，这是值得的。

洋葱架构和类似概念中最重要的概念是保持领域层的独立性。它是通过将依赖项限制为始终指向您发布的图表内部来实现的

从UI项目到域项目的引用不会违反此规则

UI层应该只为每个用例向应用层发送命令。然而，即使有这样一个清晰的关注点分离，您也可能希望在这些命令中包含一些域层对象——想到的最简单的示例是值类型和枚举

关于依赖关系的引用：

依赖规则

同心圆代表软件的不同区域。一般来说，你走得越远，软件的级别就越高。外圈是机械装置。内部圈子是政策

使此体系结构工作的最重要规则是依赖性规则。此规则表示源代码依赖项只能指向内部。内圈的任何东西都不可能知道外圈的任何东西。特别是，在外圆中声明的东西的名称不能被内圆中的代码提及。这包括，函数，类。变量或任何其他命名的软件实体

出于同样的原因，外圈中使用的数据格式不应由内圈使用，特别是如果这些格式是由外圈中的框架生成的。我们不希望外圆中的任何东西影响内圆

编辑

---

在您的评论中，您提到将实体从域层移动到应用程序核心。在中，“应用程序核心”一词是指域模型+域服务+应用程序服务。这不是一个单独的层次。

我讨厌这种教条。我认为答案取决于很多事情。如果您正在编写一个与RESTWeb服务通信的web UI，我会给您一个不同的答案。这就是像DTO层这样保持“纯度”的反模式的来源。通常情况下，事物不应该直接访问任何东西，而应该直接访问它们的邻居。因为结果很容易变成一个混乱的依赖网络。但只要你通过应用服务/app-core获得对域对象的访问权，我就看不出这是违法的。我说的是

enum

或其他

实体

。例如，当应用程序服务方法将

Enum

作为某个

实体的参数或返回对象时。在这种情况下，应该将
Enum
或
Entity
移动到核心吗？应用程序核心不是一个单独的层，它是域模型、域服务和应用程序服务的共同术语。请阅读J2EE设计模式和DTO。他们就是我所指的问题。我认为创建一个单独的对象层来镜像域模型只是为了将它们传递到UI层是一种浪费。我知道相反的做法是不可取的。但我（暂时）认为，从UI客户端中使用的域到核心层的所有内容都应该移动。将域对象用作遍历层是很常见的，但这并不意味着您必须始终以这种方式使用它。是的，但仅限于类型或枚举之类的对象。当我有一个函数（比如域实体中的方法）时，我在应用程序服务中使用它，在UI中使用应用程序服务。我假设域服务是存储库层。现在的问题是如何让我的UI层使用存储库持久化一个新的域对象。这只能使用应用程序服务来完成。因为，在将此域对象持久化到数据存储中之前，应用程序服务将验证域模型并运行一些其他规则。谢谢！现在，我假设域服务是存储库层。现在的问题是如何让我的UI层使用存储库持久化一个新的域对象。这只能使用应用程序服务来完成。因为，应用程序服务会在将此域对象持久化到data stor之前验证域模型并运行一些其他规则