потому как у меня есть сервисы уровня "модели" а есть сервисы уровня приложения

ну ты описание глянь лучше, ибо я не уверен что правильно тебя понял

Прочитал, сравнил ещё с active record как я понял row date gateway это прокачанная версия active record, AR подразумевает что весь код который отвечает за сохранение обьекта в БД и код который отвечает за что то другое в обьекте находятся в одном классе. RDG уже как бы рефакторит AR и убирает ответственность за сохранение обьекта в другой обьект, теперь условный User делегирует своё сохранение. Что предлагаю я, рефакторить Dao и Dto в RDG только инстанс dao будет один для всех экземпляров юзера. Ничего не поменяется вместо того чтобы где то держать в одной руке юзера, в другой dao мы будет говорить юзерю "сохрани себя в базу" и всё, обьект снова станет полноценным.

Прочитал, сравнил ещё с active record как я понял row date gateway это прокачанная версия active record, AR подразумевает что весь код который отвечает за сохранение обьекта в БД и код который отвечает за что то другое в обьекте находятся в одном классе. RDG уже как бы рефакторит AR и убирает ответственность за сохранение обьекта в другой обьект, теперь условный User делегирует своё сохранение. Что предлагаю я, рефакторить Dao и Dto в RDG только инстанс dao будет один для всех экземпляров юзера. Ничего не поменяется вместо того чтобы где то держать в одной руке юзера, в другой dao мы будет говорить юзерю "сохрани себя в базу" и всё, обьект снова станет полноценным.

> Прочитал, сравнил ещё с active record как я понял row date gateway это прокачанная версия active record скорее active record это сильно упрощенная row data gateway. Я не уверен что появилось раньше но вроде как не AR. > только инстанс dao будет один для всех экземпляров юзера. ну так оно как бы и в оригинале так же. Для всех инстансов один гейтвей.

или ты о том что будет лже-репрезентация "рядов"?

я плохо понимаю зачем это надо...

> Прочитал, сравнил ещё с active record как я понял row date gateway это прокачанная версия active record скорее active record это сильно упрощенная row data gateway. Я не уверен что появилось раньше но вроде как не AR. > только инстанс dao будет один для всех экземпляров юзера. ну так оно как бы и в оригинале так же. Для всех инстансов один гейтвей.

Это в дурацком переводе, что был по ссылке, в оригинале такого нет что "Объект выступает в роли шлюза к отдельной записи в источнике данных. Один экземпляр на одну запись." https://martinfowler.com/eaaCatalog/rowDataGateway.html

ну там идея что "гейтвей" это все же модель данных

она отвечает за персист. Ты же предлагаешь сделать... еще большее разделение

и у меня вопрос - зачем?

оно и так неплохо тестируется

потому как у меня есть сервисы уровня "модели" а есть сервисы уровня приложения

Ну значит. У меня есть сервисы которые могуть отвечать за выборку. Сервисы, которые отвечают за какой-либо юзкейс (Создание пользователя, запроса восстановления пароля и т.д) и есть сервисы каторые связаны с работой над файлами (та же ава пользователя, уменьшить ее, вотермарки всякие и т.д.). Просто я думаю, что все что связано с самой сущность (event которая они генерирует, dto, которые из нее собираются, exception, которые может кидать ну и репозиторий, с помощью которого мы получаем выборки ) относится к модели. Так же думаю, что сервисы, которые завязаны на юзкейсы, так же относятся к модели и должны лежать там, но их работа может зависеть от сервисов уровня приложения. Получается если я использую сервис приложения, он кидает exception, должен ли я его преобразовывать в exception уровня модели

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

она отвечает за персист. Ты же предлагаешь сделать... еще большее разделение

я хочу сделать dao деталью реализации crud методов User например

я хочу сделать dao деталью реализации crud методов User например

всеравно не понимаю)

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

Я понимаю под сервисами уровня приложения, сервисы которые работают над всем кроме как с моделями. А сервисы уровня модели это как раз юзкейсы. Разве нет?

То бишь есть у меня загрузка фото. Сервис модели просит сервис приложения загрузить фото и дать путь к нему.

всеравно не понимаю)

Ну допустим я получаю из фабрики User (передав фабрике все параметры name, age,gender) у меня этот инстанс юзера пока висит в памяти, он не персистентый, теперь я хочу его сохранить, я беру DAO передаю в этот dao User мне нужно сделать эту операцию руками условно говоря. При моём подходе я просто скажу юзеру save(); и юзер делегирует своё сохранение DAO который будет его полем. А я ничего про это DAO могу и не знать. Я скрыл реализацию.

То бишь есть у меня загрузка фото. Сервис модели просит сервис приложения загрузить фото и дать путь к нему.

сложна. Я такие сервисы называю инфраструктурой.

модель ничего не должна знать о том как происходит загрузка файлов

от слова совсем

более того, сервисы "модели" НИЧЕГО не должны знать о сервисах приложения. Если надо попользоваться инфраструктурой - используем инверсию зависимостей

ну и да, "сервисы приложения" - это по сути и есть юзкейсы. А вот сервисы модели могут реализовывать отдельные бизнес рулы, калькуляции и т.д.

короч почитай про архитектуру портов и адаптеров

там хорошо с точки зрения разделения на слои

Ну допустим я получаю из фабрики User (передав фабрике все параметры name, age,gender) у меня этот инстанс юзера пока висит в памяти, он не персистентый, теперь я хочу его сохранить, я беру DAO передаю в этот dao User мне нужно сделать эту операцию руками условно говоря. При моём подходе я просто скажу юзеру save(); и юзер делегирует своё сохранение DAO который будет его полем. А я ничего про это DAO могу и не знать. Я скрыл реализацию.

Если взять паттерн гейтвей Фаулера, и смотреть через этот контекст то DAO это гейтвей который болтается отдельно от обьектов, а его нужно вернуть на место. И тесты почти не нужно менять, DAO даже не узнает что оно теперь в поле User

Бытует мнение что наличие "сервисов модели" признак того что модель спроектирована неправильно

Бытует мнение что наличие "сервисов модели" признак того что модель спроектирована неправильно

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

причем сама суть одинаковая у всех стратегий, это "стоимость заявленная у продукта умножить на какой-то коэффициент"

а вот каким образом выбираются коэффициенты - это уже в зависимости от конфигурации

как быть?

Если взять паттерн гейтвей Фаулера, и смотреть через этот контекст то DAO это гейтвей который болтается отдельно от обьектов, а его нужно вернуть на место. И тесты почти не нужно менять, DAO даже не узнает что оно теперь в поле User

мне всегда казалось что dao это просто table gateway

от слова совсем

Хмм. Сервисы уровня приложения не относятся к модели, так?

Хмм. Сервисы уровня приложения не относятся к модели, так?

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

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

да и у Эванса похоже.... но у меня в последнее время все меньше возникает желание писать подобные сервисы...

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

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

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

у тебя будет дублирование дикое

тебе нужно подменять очень маленькую штуку

я не уверен как это делать если честно) просто у меня такая вот ситуация и то как я это разрулил мне не нравится)

Дублирование проблема локальная и есть множество паттернов для ее решения, не?

Дублирование проблема локальная и есть множество паттернов для ее решения, не?

например паттерн стратегия)

и выделение этого всего в отдельный класс

и приходим к сервисам

я не вижу проблемы, мой сервис никак не нарушает инкапсуляции сущностей

передаю я его через дабл диспатч

тестируется удобненько

Я на самом деле тоже не вижу. Но мнение такое в DDD сообществе есть.

мне всегда казалось что dao это просто table gateway

Ну это в терминологии реляционной модели, а мы в обьектной находимся, поэтому более правильное data access object, но всё равно при этом есть dto обьекты без поведения

Я на самом деле тоже не вижу. Но мнение такое в DDD сообществе есть.

ну я бы сказал что это "повод задуматься" но не еще не факт что есть проблема

Потому и написал что это только признак

как убедиться что ты более-менее понимаешь как выбирать агрегаты?

ибо я чет подозреваю что я это делаю неправильно

как минимум потому что никак не могу объяснить даже себе почему я разбил так а не иначе)

да и у Эванса похоже.... но у меня в последнее время все меньше возникает желание писать подобные сервисы...

Как вы разделяете их между собой в рамках фичи. У вас есть папка Service и Infrastructure?

Как вы разделяете их между собой в рамках фичи. У вас есть папка Service и Infrastructure?

у меня есть модуль, например Orders. В рамках него есть Handlers (это и есть юзкейсы) и Infrastructure

и есть Model

там дальше тоже разделение по "фичам" просто чуть более мелкое

но честно скажу - не сказать что я в восторге)

просто лучше ничего не придумал и в целом как показывает практика особо проблем не создает

Могу порекомендовать почитать / посмотреть Udi Dahan

Для себя очень много у него почерпнул

Могу порекомендовать почитать / посмотреть Udi Dahan

сколько раз слышал (а может даже и читал) но все никак не доберусь основательно почитать

оке, займусь

оке, займусь

Еще под инверсией, имеету ввиду, что например мой юзкейс нуждается в сервисе загрузки файлов. Он должен зависеть от интерфейса, а сервис загрузки его должен реализовать. Правильно я понимаю?

Еще под инверсией, имеету ввиду, что например мой юзкейс нуждается в сервисе загрузки файлов. Он должен зависеть от интерфейса, а сервис загрузки его должен реализовать. Правильно я понимаю?

да

и интерфейс этот принадлежит тому модулю который его юзает

а не тому кто имплементит

иначе никакой инверсии не произошло

иначе никакой инверсии не произошло

То бишь в рамках вашей структуры он лежит в handlers?

То бишь в рамках вашей структуры он лежит в handlers?

нет, мне не нужен этот сервис) мне в хэндлеры приходит уже готовый FileReference

то есть файл уже загружен на момент когда вызывается хэндлер

так что мне проще)

так что мне проще)

Но вы же где-то его создаете и переносите на файловую систему)

ну это никак к бизнес логике не относится)

я вообще сторонник подходов когда загрузка файлов должна происходить вообще отдельно от дальнейших манипуляций

типа сначала залили аватарку и потом уже создали юзера. Ну или наоброт.

2 запроса, 1 запрос тупо инфраструктура

конечно если наша предметная область не загрузка файлов (дропбокс например)

конечно если наша предметная область не загрузка файлов (дропбокс например)

Но мне кажется в этом случае смешивать инфрастуктуру с предметной тоже не очень хорошо

Но мне кажется в этом случае смешивать инфрастуктуру с предметной тоже не очень хорошо

ну как бы ты ничего и не смешиваешь. Сама работа с файловой системой будет сокрыта красивым интерфейсиком

вопрос в том что у тебя появляются сущности вроде "файла" или "директории"

просто они не совсем относятся к "файловой системе"

просто они не совсем относятся к "файловой системе"

Хмм. Например есть сущность директория, у которой метод создать в качестве зависимости он получит интерфейс инфрастутуры для работы с файловой системой и это будет нормально?

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

не, интерфейс он будет получать свой же если вообще будет получать

вообще все от логики зависит

можно просто совершенно по разному разруливать разные штуки

+ я бы все же сам процесс создания/загрузки файлов делал бы отдельно

никак не привязанным к бизнес логике.

инфраструктура может у приложения спросить "а можно я сюда залью?" и в целом этого должно хватать

Я так понимаю такой флоу выглядит намного лучше: есть отдельный ендпоинт чисто для загрузки файлов, который возращает сслыку, а вторым запросом мы создаем создаем свою модель.

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

тут весь вопрос как и что тебе делать надо)

заодно появляются всякие плюшки вроде догрузки файлов

и т.д.

просто иногда так не выйдет сделать... хотя я лично не припомню такого

Хмм. А вариант с очередью не пробовали? то бишь создаем модель но без референса на файл и кадаем в очередь задание на загрузку

Правда бывает, что модель без референса не является валидной

Хмм. А вариант с очередью не пробовали? то бишь создаем модель но без референса на файл и кадаем в очередь задание на загрузку

то есть файл уже загружен, нет?