software-design - 在洋葱、六边形或简洁架构中，域模型是否可以包含与数据库中的域模型不同的属性？

Question

我问你谁知道并有使用任何分层架构(洋葱、六边形、干净等)构建软件的经验。每当我在谷歌上搜索软件架构时，人们都会有不同的观点，并以不同的方式解释相同的架构。
条款
在您阅读问题之前，有些术语可能会让您感到困惑，因此我将在下面对其进行定义。我不确定我是否对它们有“正确”的定义，但我从互联网上收集了这些信息。如果我有误解，请告诉我。
领域层 :包含企业/业务逻辑并使用域模型。位于中心并且不依赖于除领域模型之外的任何其他层。
应用层 : 包含应用逻辑，从基础设施层接受DTO，传递View Model
DTO(数据传输对象) : 一个类，JSON 字符串等，用于在层与层之间传输数据。可能是一个纯数据容器。
VM(查看模型) :从应用层传递到表示层的DTO。
DO(域模型) : 域层中使用的类、JSON 字符串等。可能是一个纯数据容器。
VO(值对象) :数据库实体(数据库行)，或数据库使用的数据格式。可以从数据库层转移到应用层。
总结
在洋葱、六边形或简洁架构中，域层位于中心(即域层不依赖于域模型以外的任何层，域模型用于将数据传输到其他层或从更高层接受数据)。
这意味着域使用的域模型(DTO、POJO、VO 或其他)可能与数据库用于保存持久数据的模型不同。
我画了一个图表，以便我可以给你更好的解释。


第一季度 :
请看第二张图片的红色部分。
与传统的分层或 n 层架构不同，如果领域层位于中心，那么领域模型是否可以拥有比数据库实体(行)更多的属性(或不同的属性)？
例如，假设领域层使用一个名为 的类。人 .用户请求所有在服务器中注册的人的照片。让我们假设数据库只包含所有人的姓名。但是，我们可能会使用其他网络服务器通过姓名请求某人的照片。所以应用层会从数据库中读取所有的名称，并通过这些名称，通过 HTTP 请求从其他 Web 服务器获取所有图片。之后，列表人 带有名称和图片的将作为 View 模型 (DTO) 发送给用户。
Q2 :
持久层可能由数据库、文件系统、其他 Web API 等组成。
表示层可以是网站、桌面应用、移动应用、Web API 等。
这两层都是基础设施层的一部分，都依赖于应用层，而应用层只依赖于领域层。
当应用层接受来自表现层的请求时，没有问题，因为表现层调用应用层，表现层知道应用层。
大多数时候，应用层需要从持久层获取数据。
应用层无法在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何类。
这就是我目前的理解，谁能给我一个清晰的解释，数据应该如何流动以及从低层到高层的通信是如何完成的？
对于那些想写代码的人，我更喜欢 C#。

Answer 1

Q1: > can the domain model have more properties (or different properties) than the database entity (row)?

是的，它可以，因为域模型不是数据库模型。你不应该混合它们，因为它们会因不同的原因而改变。域模型(在干净架构中的实体)由于应用程序独立业务规则的更改而发生变化。数据库模型因数据持久化方式的变化而发生变化。如果将它们混合在一起，则会违反单一职责。

There is no way that the application layer can call the persistence layer without having any dependency, because it does not know any classes in the persistence layer.

This is how I am understanding so far, can someone give me a clear explanation how the data should flow and how the communication is done from the lower layer to the higher layer?

有一种方法。这称为依赖倒置。如果您正在进行结构化编程，您的代码将如下所示:

+-----+   f()    +-----+
|  A  |  ----->  |  B  |
+-----+          +-----+

有一个类 A调用方法 f上课 B .
如果您使用 C#，您将看到 using B在类 A .如果您使用的是 java，它将是 import B .不管你使用什么编程语言。类(class)名称 B将出现在 A .
但如果是 using或 import声明它意味着编译器知道。因此你有一个 编译时依赖 A -> B .
当代码执行时 控制流程 (运行时依赖)也是 A -> B .
让我们来看看另一种方法

+-----+   f()    +------------+       +-------+
|  A  |  ----->  | BInterface | <---- | BImpl |
+-----+          +------------+       +-------+

在这种情况下 A依赖于前者的抽象 B我在这里打电话 BInterface并且实现被移动到一个类 BImpl实现那个接口(interface)。
在 运行时间 控制流程仍然来自 A进入方法 f的 BImpl ，但在 编译时间 A和 BImpl依赖 BInterface因此来自 BImpl 的依赖至 BInterface积分对 控制流程 .
您可以使用多态来实现这一点。这种方法叫做 依赖倒置 ，因为您反转了依赖关系，使其指向控制流。
回到你的问题
您的应用程序层应定义一个可用于收集实体的接口(interface)。这个接口(interface)通常被称为 Repository .然后您的数据库层可以实现该 Repository (依赖倒置)。
在干净的架构中，它看起来像这样

记住用例和数据库实现之间的双线。这些线称为架构边界。越过这条线的每个依赖项都必须指向相同的方向，以遵守干净的架构依赖项规则。
还要确保您不会犯将特定于实现的东西放在接口(interface)中的错误。

An interface is an abstraction and thus tells what can be done, not how it is done.

public interface PersonRepository {

    // WRONG - because the where is usually a part of an SQL or JPQL
    // and thus exposes the implementation.
    public List<Person> findByCriteria(String where);
} 

更好的方法是

public interface PersonRepository {

    public List<Person> findByCriteria(PersonCriteria criteria);
} 

public class PersonCriteria {
    
      private String firstName;
      private MatchMode firstNameMatchMode; // something like STARTS_WITH, ENDS_WITH, CONTAINS

      // setters omitted
}

您可能想要实现更复杂的标准，但始终牢记永远不要公开实现细节。