在洋葱、六边形或干净的架构中，域模型是否可以包含与数据库中的域模型不同的属性？
In onion, hexagonal, or clean architecture, can a domain model contain different properties than the domain model in the database?
我问的是对使用任何分层架构（洋葱、六边形、干净等）构建软件非常了解并且有经验的人。每当我google谈到软件架构时，人们都有不同的观点，并以不同的方式解释同一个架构。
条款
在你阅读这个问题之前，有些术语可能会让你感到困惑，所以我在下面定义它们。我不确定我是否有它们的 'right' 定义，但我从互联网上收集了这些信息。如果我有误解，请告诉我。
领域层：包含enterprise/business逻辑并使用领域模型。位于中心，不依赖于除域模型之外的任何其他层。
应用层：包含应用逻辑，从基础设施层接受DTO，传递View Model
DTO(Data Transfer Object)：一个class，JSON字符串等，用于层与层之间传输数据出去。可能是一个纯数据容器。
VM(View Model): 从应用层传给表现层的DTO
DO (Domain Model)：领域层中使用的class、JSON字符串等。可能是一个纯数据容器。
VO (Value Object)：数据库实体（数据库行），或数据库使用的数据格式。可以从数据库层转移到应用层。
摘要
在洋葱、六边形或干净的架构中，域层位于中心（即域层不依赖于域模型以外的任何层，域模型用于将数据传输到其他层或从中接受数据高层）。
这意味着域使用的域模型（DTO、POJO、VO 或其他）可能与数据库用于保存持久数据的模型不同。
我画了一张图，以便更好地解释。
Q1:
请看第二张图红色部分
如果领域层与传统的分层或 n-tier 架构不同，领域层位于中心，那么领域模型是否可以比数据库实体（行）具有更多的属性（或不同的属性）？
例如，假设领域层使用一个叫做Person的class。用户请求在服务器上注册的所有人的照片。让我们假设数据库只包含所有人的名字。但是，我们可能会使用其他网络服务器通过姓名请求某人的照片。因此应用层将从数据库中读取所有名称，并使用这些名称通过 HTTP 请求从其他 Web 服务器获取所有图片。之后，Person 的列表以及姓名和图片将作为视图模型（DTO）发送给用户。
Q2:
持久层可能由数据库、文件系统、其他网络API等组成
表示层可能是网站、桌面应用程序、移动应用程序、网络API等
这两层都是基础设施层的一部分，依赖于应用层，但应用层只依赖领域层。
当应用层接受来自表现层的请求时，没有问题，因为表现层调用应用层，表现层知道应用层。
大多数时候，应用层需要从持久层获取一个数据。
应用层无法在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何classes。
到目前为止我是这样理解的，有人能给我一个清楚的解释数据应该如何流动以及如何从下层到上层进行通信吗？
对于想写代码的人，我更喜欢C#。
Q1: Can the domain model have more properties (or different
properties) than the database entity (row)?
当然可以。两种模型可能具有不同的属性。 “持久端口”（“存储库”）实现，即适配器会将一种模型相互转换。
Q2:
In most of the time, the application layer needs to get a data from
the persistence layer.
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.
为了从持久层获取数据，应用层调用“存储库”（DDD 术语），即“用于持久化数据的端口”（十六进制术语）。这个repository（端口）属于domain，所以应用层调用domain层。
一个数据库适配器实现了端口。适配器属于基础结构层，这没关系，因为基础层不仅依赖于应用层，还依赖于域。
如果你有兴趣，这里是我关于六边形建筑的文章：
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 |
+-----+ +-----+
有一个 class A 在 class B.
上调用方法 f
如果您使用的是 C#，您将在 class A 中看到一个 using B。如果您使用 java，它将是 import B。不管你使用什么编程语言。 class B 的名字会出现在 A.
但是如果它是一个using或import语句就意味着编译器知道。因此你有一个编译时间依赖 A -> B.
执行代码时，控制流（运行时依赖性）也是A -> B.
让我们看看另一种方法
+-----+ f() +------------+ +-------+
| A | -----> | BInterface | <---- | BImpl |
+-----+ +------------+ +-------+
在这种情况下 A 取决于我在这里调用的前 B 的抽象 BInterface 并且实现被移动到 class BImpl 实现该接口。
在运行时，控制流仍然从A进入[=31的方法f =]，但在 编译时 A 和 BImpl 依赖于 BInterface，因此依赖性从 BImpl 到 BInterface 反对 控制流 。
您可以使用多态性来实现这一点。这种方法称为依赖反转，因为你反转了依赖，使其指向控制流。
回到你的问题
您的应用程序层应定义可用于收集实体的接口。此接口通常称为 Repository。然后，您的数据库层可以实现 Repository（依赖倒置）。
在干净的架构中它看起来像这样
记住用例和数据库实现之间的双线。这些线称为架构边界。越过这条线的每个依赖项都必须指向同一方向，以遵守干净的架构依赖项规则。
还要确保您没有犯将特定于实现的内容放在接口中的错误。
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
}
您可能想要实施更复杂的标准，但请始终记住，您永远不应公开实施细节。
我问的是对使用任何分层架构（洋葱、六边形、干净等）构建软件非常了解并且有经验的人。每当我google谈到软件架构时，人们都有不同的观点，并以不同的方式解释同一个架构。
条款
在你阅读这个问题之前，有些术语可能会让你感到困惑，所以我在下面定义它们。我不确定我是否有它们的 'right' 定义，但我从互联网上收集了这些信息。如果我有误解，请告诉我。
领域层：包含enterprise/business逻辑并使用领域模型。位于中心，不依赖于除域模型之外的任何其他层。
应用层：包含应用逻辑，从基础设施层接受DTO，传递View Model
DTO(Data Transfer Object)：一个class，JSON字符串等，用于层与层之间传输数据出去。可能是一个纯数据容器。
VM(View Model): 从应用层传给表现层的DTO
DO (Domain Model)：领域层中使用的class、JSON字符串等。可能是一个纯数据容器。
VO (Value Object)：数据库实体（数据库行），或数据库使用的数据格式。可以从数据库层转移到应用层。
摘要
在洋葱、六边形或干净的架构中，域层位于中心（即域层不依赖于域模型以外的任何层，域模型用于将数据传输到其他层或从中接受数据高层）。
这意味着域使用的域模型（DTO、POJO、VO 或其他）可能与数据库用于保存持久数据的模型不同。
我画了一张图，以便更好地解释。
Q1:
请看第二张图红色部分
如果领域层与传统的分层或 n-tier 架构不同，领域层位于中心，那么领域模型是否可以比数据库实体（行）具有更多的属性（或不同的属性）？
例如，假设领域层使用一个叫做Person的class。用户请求在服务器上注册的所有人的照片。让我们假设数据库只包含所有人的名字。但是，我们可能会使用其他网络服务器通过姓名请求某人的照片。因此应用层将从数据库中读取所有名称，并使用这些名称通过 HTTP 请求从其他 Web 服务器获取所有图片。之后，Person 的列表以及姓名和图片将作为视图模型（DTO）发送给用户。
Q2:
持久层可能由数据库、文件系统、其他网络API等组成
表示层可能是网站、桌面应用程序、移动应用程序、网络API等
这两层都是基础设施层的一部分，依赖于应用层，但应用层只依赖领域层。
当应用层接受来自表现层的请求时，没有问题，因为表现层调用应用层，表现层知道应用层。
大多数时候，应用层需要从持久层获取一个数据。
应用层无法在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何classes。
到目前为止我是这样理解的，有人能给我一个清楚的解释数据应该如何流动以及如何从下层到上层进行通信吗？
对于想写代码的人，我更喜欢C#。
Q1: Can the domain model have more properties (or different properties) than the database entity (row)?
当然可以。两种模型可能具有不同的属性。 “持久端口”（“存储库”）实现，即适配器会将一种模型相互转换。
Q2:
In most of the time, the application layer needs to get a data from the persistence layer.
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.
为了从持久层获取数据，应用层调用“存储库”（DDD 术语），即“用于持久化数据的端口”（十六进制术语）。这个repository（端口）属于domain，所以应用层调用domain层。
一个数据库适配器实现了端口。适配器属于基础结构层，这没关系，因为基础层不仅依赖于应用层，还依赖于域。
如果你有兴趣，这里是我关于六边形建筑的文章：
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 |
+-----+ +-----+
有一个 class A 在 class B.
f
如果您使用的是 C#，您将在 class A 中看到一个 using B。如果您使用 java，它将是 import B。不管你使用什么编程语言。 class B 的名字会出现在 A.
但是如果它是一个using或import语句就意味着编译器知道。因此你有一个编译时间依赖 A -> B.
执行代码时，控制流（运行时依赖性）也是A -> B.
让我们看看另一种方法
+-----+ f() +------------+ +-------+
| A | -----> | BInterface | <---- | BImpl |
+-----+ +------------+ +-------+
在这种情况下 A 取决于我在这里调用的前 B 的抽象 BInterface 并且实现被移动到 class BImpl 实现该接口。
在运行时，控制流仍然从A进入[=31的方法f =]，但在 编译时 A 和 BImpl 依赖于 BInterface，因此依赖性从 BImpl 到 BInterface 反对 控制流 。
您可以使用多态性来实现这一点。这种方法称为依赖反转，因为你反转了依赖，使其指向控制流。
回到你的问题
您的应用程序层应定义可用于收集实体的接口。此接口通常称为 Repository。然后，您的数据库层可以实现 Repository（依赖倒置）。
在干净的架构中它看起来像这样
记住用例和数据库实现之间的双线。这些线称为架构边界。越过这条线的每个依赖项都必须指向同一方向，以遵守干净的架构依赖项规则。
还要确保您没有犯将特定于实现的内容放在接口中的错误。
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
}
您可能想要实施更复杂的标准，但请始终记住，您永远不应公开实施细节。