在洋葱、六边形或干净架构中，域模型是不是可以包含与数据库中的域模型不同的属性？

Posted 2023-02-15

技术标签:

【中文标题】在洋葱、六边形或干净架构中，域模型是不是可以包含与数据库中的域模型不同的属性？【英文标题】：In onion, hexagonal, or clean architecture, can a domain model contain different properties than the domain model in the database?在洋葱、六边形或干净架构中，域模型是否可以包含与数据库中的域模型不同的属性？ 【发布时间】：2020-12-23 13:26:28 【问题描述】：

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

条款

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

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

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

DTO（数据传输对象）：一个类，JSON字符串等，用于在层之间传入和传出数据。可能是一个纯数据容器。

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

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

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

摘要

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

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

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

第一季度：

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

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

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

第二季度：

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

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

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

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

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

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

这就是我目前的理解，谁能给我一个清楚的解释数据应该如何流动以及如何从低层到高层进行通信？

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

【问题讨论】：

【参考方案1】：

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

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

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

这就是我目前的理解，谁能给我一个清楚的解释数据应该如何流动以及如何从低层到高层进行通信？

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

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

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

如果您使用 C#，您将在 A 类中看到 using B。如果您使用的是 java，它将是 import B。无论您使用哪种编程语言。类名B 将出现在A 中。

但如果是using 或import 语句，则意味着编译器知道。因此你有一个编译时依赖 A -> B。

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

让我们看看另一种方法

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

在这种情况下，A 依赖于我在此称为 BInterface 的前B 的抽象，并且实现被移动到实现该接口的类 BImpl。

在运行时，控制流仍然从A进入BImpl的方法f，但在编译时 A 和 BImpl 依赖于 BInterface，因此从 BImpl 到 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

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

【讨论】：

【参考方案2】：