5

我问你谁知道并且有使用任何分层架构（洋葱、六边形、干净等）构建软件的经验。每当我在谷歌上搜索软件架构时，人们都会有不同的观点，并以不同的方式解释相同的架构。

条款

在您阅读问题之前，有些术语可能会让您感到困惑，因此我在下面对其进行定义。我不确定我是否对它们有“正确”的定义，但我从互联网上收集了这些信息。如果我有误解，请告诉我。

领域层：包含企业/业务逻辑并使用领域模型。位于中心，不依赖于域模型以外的任何其他层。

应用层：包含应用逻辑，接受来自基础设施层的DTO，传递View Model

DTO（Data Transfer Object）：一个类，JSON字符串等，用于在层之间传输数据。可能是纯数据容器。

VM（视图模型）：从应用层传递到表示层的 DTO。

DO（Domain Model）：领域层使用的类、JSON字符串等。可能是纯数据容器。

VO（值对象）：数据库实体（数据库行），或数据库使用的数据格式。可以从数据库层转移到应用层。

概括

在洋葱、六边形或干净架构中，域层位于中心（即域层不依赖于域模型以外的任何层，域模型用于将数据传输到其他层或接受来自更高层的数据）。

这意味着域使用的域模型（DTO、POJO、VO 或其他）可能与数据库用于保存持久数据的模型不同。

我画了一张图，以便给你更好的解释。

在此处输入图像描述

在此处输入图像描述

Q1：

请看第二张图片的红色部分。

如果领域层在中心，不像传统的分层或n层架构，领域模型能否比数据库实体（行）拥有更多的属性（或不同的属性）？

例如，假设域层使用一个名为Person的类。用户请求在服务器中注册的所有人的照片。让我们假设数据库只包含所有人的姓名。但是，我们可能会使用其他网络服务器通过姓名请求人的照片。所以应用层会从数据库中读取所有的名字，通过这些名字，它会通过一个HTTP请求从其他web服务器获取所有的图片。之后，带有名称和图片的Person列表将作为视图模型 (DTO) 发送给用户。

Q2：

持久层可能由数据库、文件系统、其他 Web API 等组成。

表示层可能是网站、桌面应用程序、移动应用程序、Web API 等。

这两层都是基础设施层的一部分，依赖于应用层，但应用层只依赖于领域层。

当应用层在接受来自表现层的请求时，没有问题，因为表现层调用应用层并且表现层知道应用层。

大多数时候，应用层需要从持久层获取数据。

应用层不可能在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何类。

到目前为止我的理解是这样的，有人可以给我一个清楚的解释数据应该如何流动以及如何从较低层到较高层进行通信吗？

对于那些想写代码的人，我更喜欢 C#。

4

2 回答 2

3

Q1：> 领域模型能否比数据库实体（行）拥有更多的属性（或不同的属性）？

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

应用层不可能在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何类。

到目前为止我的理解是这样的，有人可以给我一个清楚的解释数据应该如何流动以及如何从较低层到较高层进行通信吗？

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

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

有一个类A调用 class 上的f方法B。

如果您使用的是 C#，您将看到一个using Bin class A。如果您使用的是 java，它将是一个import B. 无论您使用哪种编程语言。班级名称B将出现在A.

但如果它是一个usingorimport语句，则意味着编译器知道。因此，您有一个编译时依赖项 A-> B。

当代码被执行时，控制流（运行时依赖）也是A-> B。

让我们看看另一种方法

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

在这种情况下A，取决于B我在这里调用的前者的抽象，BInterface并将实现移至BImpl实现该接口的类。

在运行时，控制流仍然是 from Ainto 的方法f，BImpl但在编译时 A并BImpl依赖于BInterface，因此 fromBImpl到的依赖关系BInterface指向控制流。

您可以使用多态性来实现这一点。这种方法称为依赖倒置，因为您倒置了依赖，使其指向控制流。

回到你的问题

您的应用程序层应定义一个可用于收集实体的接口。此接口通常称为Repository. 然后您的 db 层可以实现它Repository（依赖倒置）。

在干净的架构中，它看起来像这样

干净的架构

记住用例和数据库实现之间的双线。这些线称为架构边界。越过这条线的每个依赖项都必须指向同一个方向，以遵守干净的架构依赖项规则。

还要确保你不会犯将实现特定的东西放在接口中的错误。

接口是一种抽象，因此它告诉我们可以做什么，而不是如何完成。

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
}

您可能希望实现更复杂的标准，但请始终牢记您永远不应该公开实现细节。

于 2020-09-05T05:58:42.667 回答
2

Q1：领域模型能否拥有比数据库实体（行）更多的属性（或不同的属性）？

当然。两种模型可能具有不同的属性。“持久性端口”（“存储库”）实现，即适配器将一个模型相互转换。

Q2：

大多数时候，应用层需要从持久层获取数据。

应用层不可能在没有任何依赖的情况下调用持久层，因为它不知道持久层中的任何类。

为了从持久层获取数据，应用层调用“存储库”（DDD 术语），即“持久数据端口”（hex arch 术语）。这个存储库（端口）属于域，所以应用层调用域层。

数据库适配器实现端口。适配器属于基础设施层，这没关系，因为基础设施层不仅依赖于应用层，还依赖于域。

如果您有兴趣，这是我关于六边形架构的文章：

https://jmgarridopaz.github.io/content/articles.html

于 2020-09-04T20:01:02.593 回答