Что на самом деле представляет собой модель домена в архитектуре портов и адаптеров?

Question

Поскольку в последнее время я много читал об архитектуре портов и адаптеров, я наткнулся на этот фрагмент кода как часть приложения, созданного в соответствии с вышеупомянутой архитектурой:

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 постоянная библиотека? Насколько я понимаю, доменный уровень отвечает только за реализацию сценариев использования. Я действительно сбит с толку относительно того, что на самом деле должно быть доменным уровнем в архитектуре этого типа.

Answer 1

Отличный вопрос, сначала обратите внимание, что гексагональная архитектура не имеет слоев. Гексагональная архитектура имеет приложение и адаптеры с односторонними отношениями между ними, не более того. Там нет доменного слоя.

Приложение связывается со своими адаптерами, используя простые POJO (без импорта). Они живут в приложении и используются адаптерами. Когда адаптеру необходимо настроить (адаптировать) один из этих POJO, он реализует свою собственную версию этого объекта (например, с помощью композиции или наследования). Это разделяет домен на то, что вы могли бы назвать API домена и реализацию домена.

API домена указывается приложением. Этот API должен быть независим от технологий, используемых адаптерами. Так что вы правильно сказали, что javax.persistence не принадлежит API домена внутри приложения.

Рассматриваемый пример кода - это то, что вы можете назвать реализацией домена. Он включает в себя "подключаемые" технологии, о которых приложение (и должно оставаться) не знает.

Таким образом, вы бы поместили POJO в приложение (без постоянных аннотаций), а вышеприведенный код будет жить, например, в адаптере реляционной базы данных, который преобразует реализацию его домена в API домена приложения.

Answer 2

Поскольку основная цель архитектуры портов и адаптеров состоит в том, чтобы отделить и изолировать уровень домена от любых технических деталей и реализаций

Цель состоит в том, чтобы изолировать приложение от вещей, которые не относятся к реальной проблеме, которую приложение должно решить. Это устройства ввода / вывода, базы данных, технологические структуры и т. Д. Код приложения должен быть чистым кодом. Но шаблон ничего не говорит о том, как вы должны структурировать внутреннюю часть шестиугольника. У вас может быть доменный слой или нет, решать вам.

этот пользовательский объект на самом деле является доменным слоем, не содержит ли он зависимости от библиотеки персистентности java?

Предполагая, что у вас есть модель домена внутри приложения с сущностью User, код, который вы здесь показываете, не является той сущностью User. Модель предметной области. Пользовательский объект должен быть независимым от технологий, без аннотаций, без кода структуры. Код, показанный здесь, будет принадлежать адаптеру постоянства, который использует JPA для доступа к базе данных. В этом адаптере вам придется выполнять перевод между сущностью User модели домена и этой сущностью JPA User.

Насколько я понимаю, доменный уровень отвечает только за реализацию сценариев использования.

Согласно DDD (проектирование на основе домена), уровень домена не реализует сценарии использования. Прикладной уровень делает. И прикладной уровень вызывает уровень домена, чтобы сделать это. Но эти понятия слоев, DDD и т. Д. Не имеют ничего общего с архитектурой портов и адаптеров. Шаблон ничего не говорит об этом.

Я действительно сбит с толку относительно того, что на самом деле должно быть доменным уровнем в архитектуре этого типа.

Эта архитектура ничего не говорит о том, каким должен быть уровень домена. Эта архитектура просто говорит о том, что у вас есть приложение (шестиугольник), порты (API/SPI, принадлежащие шестиугольнику) и адаптеры (вне шестиугольника). Какие бы слои вы ни поместили внутри шестиугольника, решать вам, будь то Доменный слой или что-то еще.