DDD, JPA и конструкторы не по умолчанию

Question

DDD говорит, что ваши доменные модели должны быть выразительными и говорить то, что им нужно. Имея это в виду, я создал следующий класс:

@Entity
public class User{
    @Id
    @GeneratedValue
    private Long id;

    private String userName;
    private String password;

    public User(String userName, String password) {
        /**set the values*/
    }

    /** Validations, getters and business methods*/

С помощью этого конструктора я говорю, что минимум, необходимый для создания нового объекта User.

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

Answer 1

В вашей конкретной ситуации c вы можете сделать конструктор без аргументов закрытым. Но вскоре другое требование JPA заставит вас сделать еще один обходной путь:

voiceofunreason дал вам правильный ответ. Правильный путь - это иметь адаптер на уровне инфраструктуры / персистентности, который принимает ваш доменный объект, а затем конвертировать его в модель JPA anemi c и наоборот.

Некоторые другие параметры, которые подходят лучше без особых затрат. преобразования:

1 - данные пружины JDB C пытается усвоить концепцию агрегатов

• https://www.youtube.com/watch?v=GOSW911Ox6s&t=3s;
• https://docs.spring.io/spring-data/jdbc/docs/1.1.7.RELEASE/reference/html/#reference

2 - Сохраните ваш агрегат как json в реляционной базе данных. Вон Вернон предложил реализацию -> https://kalele.io/the-ideal-domain-driven-design-aggregate-store/

3 - База данных, ориентированная на документы, например, https://www.mongodb.com/ среди других ...

Answer 2

В этом случае я должен забыть об этом DDD sugestion или есть обходной путь?

Здесь нет действительно хорошего ответа. В работе возникает напряжение, когда мы пытаемся смешивать объекты с изменяемым, инкапсулированным состоянием и постоянством (ie: сохранение достоверной копии состояния в некотором долговременном хранилище anemi c).

«Право» ответ в том, что мы не используем O / RM для загрузки доменных сущностей из долговременного хранилища; O / RM загружает DTO, и мы копируем информацию из DTO в объект домена. Аналогично, для сохранения вы извлекаете информацию из доменного объекта и копируете ее в DTO, а затем сохраняете DTO.

Другими словами, O / RM загружает в память представление структуры данных anemi c.

На практике гораздо чаще связывать состояние объекта с O / RM, реализуя в объекте домена все интерфейсы, которые необходимы O / RM для выполнения своей работы.

Хитрость заключается в том, чтобы убедиться, что вы можете отделить свою реализацию от O / RM, когда начнутся предположения O / RM. мешать. Например, вы должны иметь возможность легко изменить заданный c агрегат с использования реляционного хранилища данных на использование хранилища данных документа без необходимости перезаписи всей вашей системы.