Как правильно писать сущности в доменном слое для разных юс-кейсов?

Question

[No_name451]

Поглядываю на чистую/лукову/гексагональную архитектуру

До этого работал на дефолтном MVC (MTV) - Django. Соответственно четкого обозначения доменного слоя не видел, слои сильно 'просачивались' друг в друга, + наличие орм - тоже давало возможность не реализовать доменные модели, которой всегда пользовались

Но в перечисленных выше архитектурах - доменный слой является главным. Причем, написан он должен быть по канону без сторонних библиотек, то есть быть POJO (Java) / POCO (.net) / POPO (Python).

И вот у меня назрел вопрос - как реализовать класс под какую-то сущность в доменном слое, если эта сущность используется во многих юс-кейсах, например:
1 юс-кейс использует все 10 полей из 10. Например - формирование 'досконального отчета' по списку сущностей
2 юс-кейс использует всего 7 полей из 10
3 юс-кейс использует всего 4 поля из 10. Например - формирование 'верхнеуровнего отчетика' по списку сущностей

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

Но как правильно в таком случае должен выглядеть класс(ы) этой сущности в доменном слое, если вначале был представлен только 1 юс-кейс и под эту сущность написали класс с базовой логикой проверок на инварианты, при этом все 10 'атрибутов' были обязательны, НО потом появился 2 юс-кейс, где требуется 7 из 10 полей? Оставлять этот же класс под эту сущность, но внести в него изменения - сделать ему 3 'атрибута' не обязательными? Но ведь тогда возможна ситуация, когда для 1 юс-кейса будет не хватать обязательных для него 'атрибутов' + вроде как нарушается O из SOLID.
Ну и дальше развивая - появился 3 юс-кейс, где нужно 4 из 10 полей - тоже оставлять один класс и делать еще 3 'атрибута' не обязательными (тогда это ломает логику двух других юс-кейсов) - поступать как уже ранее предположил?
Либо, чисто в теории - можно плодить на каждый юс-кейс конкретный класс (то есть несколько классов на одну сущность) через механизм наследования, где и переопределять значение ненужных 'атрибутов' на пустое значение - но нормально ли это?

Answer 1

[baseddepartment]

Сложилось впечатление, что ты не совсем понимаешь, что такое Use Case. Use Case - это какой-то бизнес сценарий, состоящий из от 1 до n шагов. То, что, как мне показалось, ты описываешь, это - "Interactor" a.k.a Паттерн "Command", он и является шагом юзкейса.

И вот у меня назрел вопрос - как реализовать класс под какую-то сущность в доменном слое, если эта сущность используется во многих юс-кейсах,

Зависит от сложности твоего домена, можно нарезать твое приложения по юз кейсам и сделать из каждого юз кейса отдельный модуль, в котором будут находиться доменные сущности хранящие только те данные, которые нужны юз кейсу.

Например - формирование 'досконального отчета' по списку сущностей

Это непохоже на interactor, interactor как-то меняет состояние системы, а это просто получение данных, тут, в общем-то, и доменные сущности не нужны, скорее просто какой-нибудь интерфейс к бд, которые собирает твоей "отчет".

при этом нужно помнить о перфомансе - тянуть все поля абсолютно во всех юс-кейсах не правильно

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

вроде как нарушается O из SOLID.

Open–closed principle вообще никак не связан с тем, что ты описал.

Если интересно почитать про то, как организовывать доменную модель, советвую почитать "Шаблоны корпоративных приложений. Мартина Фаулера" и что-нибудь про DDD.

Comments

[No_name451]

Благодарю за комментарий!

С этим:

Use Case - это какой-то бизнес сценарий, состоящий из от 1 до n шагов.

согласен и даже добавлю - юс кейс не обязан включать в себя функционал по изменению состояния системы.

При этом - формирование отчета может проходить далеко не только на стороне БД + иметь под собой n-шагов.
Например:
Шаг 1: Забравть сырые данные, без условий выборки забрать из БД средствами SQL/NoSQL
Шаг 2: Пропустить их через сложную/хитрую обработку, которую не возможно реализовать на стороне БД (и вполне вероятно что этого не нужно делать)
Шаг 3: Конвертировать проанализированные данные в требуемый выходной формат (xlsx/json/pdf/...)
Шаг 4: Оповестить пользователя/другую систему/... что работа завершена

Для справки:
Data Lake/Warehouse идут рука-об-руку с шагами 1, 2. Но там все посложнее и имеет свою специфику:)

Еще я не понимаю, к чему эти противоречивые тейки...
Вначале ты говоришь это:

То, что, как мне показалось, ты описываешь, это - "Interactor" a.k.a Паттерн "Command", он и является шагом юзкейса.

После - это:

Это непохоже на interactor, interactor как-то меняет состояние системы, а это просто получение данных

Зачем и о чем это?..

при этом нужно помнить о перфомансе - тянуть все поля абсолютно во всех юс-кейсах не правильно

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

Ага, тянуть абсолютно все поля - нормально... Я тебя понял:)

Теперь к:

Open–closed principle вообще никак не связан с тем, что ты описал.

Как раз таки связан.

Я описал 2 возможных варианта решения сложившейся ситуации, которые мне с ходу пришли в голову.
Также, прошу заметить, что я нигде не говорил о том, что эти 2 варианта являются production-ready решениями.
Это плохие примеры решений 'в лоб', как раз нацеленные на то чтобы дать будущему комментатору больше контекста -
что я действительно не знаю как решить эту ситуацию 'красиво'/'правильно'/production-ready и поэтому прошу помощи.

И так, принцип Open–closed principle связан с примером, где поястоянно вносятся изменения в один класс (для атрибутов задается значение по умолчанию, равное Null/None/...), из-за того что появляются новые юс-кейсы со своими потребностями.

Если интересно почитать про то, как организовывать доменную модель, советвую почитать "Шаблоны корпоративных приложений. Мартина Фаулера" и что-нибудь про DDD.

Спасибо за предложение.
Первую книгу я почти прочитал, с паттернами для работы с бизнес-логикой я знаком.
Про DDD - Эванса намеренно не стал читать. Прочитал Вернона - Domain-Driven Design Distilled, Влада - Learning Domain-Driven Design.
Там (как и большинстве технической литературы) явного ответа как поступать в таких кейсах - нет.

И вот у меня назрел вопрос - как реализовать класс под какую-то сущность в доменном слое, если эта сущность используется во многих юс-кейсах,

Зависит от сложности твоего домена, можно нарезать твое приложения по юз кейсам и сделать из каждого юз кейса отдельный модуль, в котором будут находиться доменные сущности хранящие только те данные, которые нужны юз кейсу.

Спасибо. Тоже об этом думал, но если в доменная сущность претерпит какие-то сильные/глобальные измения - эти измения небохдоимо применить во всех местах, где это потребуется.
То есть потенциально, при таком подходе - таких мест будет больше.
А уже это - потенциально может привести к ситуации где не всё привели в ожидаемый вид - то есть допустили ошибку из-за человеческого фактора.
Да и про DRY думаю стоит помнить, когда для двух разных юс-кейсов, но со схожим атрибутивным составом на процентов 60-70 будет писаться 2 разных доменных модели.

[baseddepartment]

No_name451,

согласен и даже добавлю - юс кейс не обязан включать в себя функционал по изменению состояния системы.

Вроде в книжке Роберта Мартина он их не разделяет, да, тут ошибка вышла.

И так, принцип Open–closed principle связан с примером, где поястоянно вносятся изменения в один класс (для атрибутов задается значение по умолчанию, равное Null/None/...), из-за того что появляются новые юс-кейсы со своими потребностями.

У тебя неправильное понимает этого принципа. Open-Closed principle - не про "нельзя менять старый код, можно добавлять только новый", он про изменение работы метода, не меняя сам метод. Например, наследование от класса и переопределение метода, или разбить метод на функции, занижектить их в наш объект и вызывать внутри метода, и, в случае, если что-нибудь нужно будет изменить, мы будем менять функции, которые мы заинжектили, а не наш метод, и т.д.

Там (как и большинстве технической литературы) явного ответа как поступать в таких кейсах - нет

Ну как нет то? В DDD принято грузить полностью агрегат для выполнения какой то операции, которая может не потребовать и половины данных, которые ты загрузил. Ну, или вспомнить даже знаменитую триллему, где иногда прибегают к потери производительности, чтобы не потерять 2 других свойства домена.

Тоже об этом думал, но если в доменная сущность претерпит какие-то сильные/глобальные измения - эти измения небохдоимо применить во всех местах, где это потребуется.

Если ты порежешь приложение по юзкейсам, то будет разумно, в каждом юзкейсе создавать свою сущность, которая может быть похожа на сущность из другого юзкейса, но тем не менее, будет иметь другой смысл. Но если у тебя появляется такая необходимость - значит домен сложный и тут лучше делать на агрегаты, а не на анемичные модели.

Просто дели на модели для представления и на модели для бизнес логики, а все остальное это мелочи, и не надо забивать этим голову.