端口和适配器架构中的域模型实际上是什么？答案

【问题标题】：What is actually the Domain Model in Ports and Adapters architecture?端口和适配器架构中的域模型实际上是什么？
【发布时间】：2018-02-26 13:33:37
【问题描述】：

由于我最近阅读了很多关于端口和适配器架构的内容，我偶然发现这段代码是按照上述架构构建的应用程序的一部分：

package com.example.user.management;

import lombok.*;

import javax.persistence.*;
import java.io.Serializable;

@Table(name = "user")
@AllArgsConstructor
@Data
@NoArgsConstructor
@javax.persistence.Entity
@Setter
@Getter
@Inheritance(strategy = InheritanceType.TABLE_PER_CLASS)
public class User implements Serializable {
    @Id
    @GeneratedValue(strategy = GenerationType.TABLE)
    private Long id;

    @Column(name = "username")
    private String username;

    @Column(name = "password")
    private String password;

    @Column(name = "role")
    private String role;

    public User(String username, String password, String role) {
        this.username = username;
        this.password = password;
        this.role = role;
    }

}

由于端口和适配器架构的主要意图是将域层与任何技术细节和实现分开和隔离，并记住这个用户实体实际上是域层，它不包含依赖关系到java持久性库？据我了解，域层仅负责实现用例。对于这种架构中的域层实际上应该是什么，我真的很困惑。

【问题讨论】：

所以没有人费心去创建一个 DAO（以及所有的映射）。
我猜这是因为演示似乎是简单的 CRUD 应用程序。但由于端口和适配器（六边形）架构旨在用于大型企业项目，因此不应该出现这种情况。
不，但在演示中通常是这样。不要假设太多。
是的，但是这个演示违反了架构的基本规则——领域模型不应该依赖于任何技术栈。
'领域层只负责实现用例' 个人认为是应用层实现用例。

标签： design-patterns architecture hexagonal-architecture

【解决方案1】：

很好的问题，首先注意六边形架构没有层。六边形架构有一个应用程序和适配器，两者之间是单向关系，仅此而已。没有领域层。

应用程序仅使用 POJO（无导入）与其适配器进行通信。它们存在于应用程序中并由适配器共享。当适配器需要自定义（adapt）这些 POJO 之一时，它会实现该对象的自己的自定义版本（例如，通过组合或继承）。这会将域拆分为您可能称之为域 API 和域实现的部分。

域 API 由应用程序指定。此 API 必须与适配器使用的技术无关。所以你说javax.persistence 不属于应用程序内部的域API 是正确的。

有问题的代码示例是您可能称之为域实现的内容。它包括应用程序不知道（并且必须保持）不知道的“插件”技术。

所以你可以在应用程序中放置一个 POJO（没有持久性注释），上面的代码将存在于例如内部。一个关系数据库适配器，它将其域实现转换为应用程序的域 API。

【讨论】：

所以只是为了检查我是否在同一页面上。域逻辑（又名所有用例）将是简单的 POJO 类。关系数据库适配器（或任何其他持久性适配器）将包含特定于技术的域模型实现。通过这样做，我满足了依赖流总是趋向于中心而不是相反的规则。我只是好奇如何通过继承来实现，Entity 类只会继承 POJO 类？
域逻辑（用例）在具有状态和行为的成熟对象中实现。逻辑的输入和输出是 POJO。适配器通过发送和接收 POJO 与域逻辑进行通信。适配器可以子类化 POJO 以进行定制；但是组合通常更可取，因为继承对于代码重用来说是一个糟糕的工具。
'但是组合通常更可取，因为继承对于代码重用来说是一个糟糕的工具。 ' 但组合需要额外的逻辑和代码乘法。如果安全用户 [安全] -> 用户 -> 域用户。我认为对于典型的域业务模型而言，组合是更好的选择，而不仅仅是像用户这样的简单 CRUD..

【解决方案2】：

端口和适配器架构的主要意图是将领域层与任何技术细节分离和隔离实现

目的是将应用程序与不属于应用程序必须解决的实际问题的事物隔离开来。这些东西是输入/输出设备、数据库、技术框架等。应用程序代码必须是干净的代码。但是该模式没有说明您必须如何构造六边形的内部。你可能有或没有领域层，这取决于你。

这个User实体其实就是领域层，它不包含对java持久化库的依赖？

假设您在 de 应用程序中有一个带有 User 实体的域模型，那么您在此处显示的代码不是该 User 实体。域模型用户实体必须与技术无关，没有注释，没有框架代码。您在此处显示的代码将属于使用 JPA 访问数据库的持久性适配器。在该适配器中，您必须在域模型的用户实体和此 JPA 用户实体之间进行转换。

据我了解，领域层只负责实施用例。

根据 DDD（领域驱动设计），领域层不实现用例。应用层可以。应用层调用领域层来做到这一点。但是这些层、DDD 等概念与端口和适配器架构无关。该模式对此一无所知。

我真的很困惑实际上应该是什么领域层在这种类型的架构中。

这个架构没有说明领域层应该是什么。这个架构只是说你有一个应用程序（六边形）、端口（属于六边形的 API/SPI）和适配器（在六边形之外）。您在六边形中放置的任何层都取决于您，是域层还是其他。

【讨论】：