Если честно моё мнение что в ИТ очень многие решения принимаются эмоционально, некий массовый психоз проплаченный гигантами индустрии (микросервисы, джаваскрипт). Необходимо воздействовать не только на мозг инженера, но и на людей которые принимают финансовые решения. Поэтому микросервисы и джаваскрипт должны быть везде и под сомнения их ставить не должно быть принято)
P.S. перечитал ваш комментарий - а ведь действительно, по итогу сам разработчик по той или иной причине становится лоббистом всяких странных решений)
Идея до разработчика часто доходит не в изначальном смысле (собственное погружение в проблемы и изучение), а уже переваренная индустрией
Вот и получаеются микросервисы с луковичной архитектурой)
Или вот кэш, я думаю знающие люди понимают как сложно сделать прослойку кэша для бд. Сколько раз я видел redis которые по факту стоит в стороне от системы (торгует лицом, осваивает бюджет) а по бумагам редис чуть ли не из главных хранилищь, когда я указал на это тимлиду и начальнику департамента, что подрядчик редисом просто бабки в договоре отмывает, как же на меня тогда накинулись мои же коллеги)) Какое-то массовое помещательство)
Интересно конечно почему не стоит очередь из перформеров в компанию "сил добра", чтобы пробиться через кучу собеседований и начать за 100-200к обучать тимлидов инверссии зависимости))
Кто мне не верит - попросите автора вынести слой домена из приложения, замокать его и протестировать бизнес кейсы.
А я вам сразу скажу что здесь так не получится, здесь нет никакого домена, здесь куча модулей со "слоеной" архитектурой где лежит папочка "домен", это все что объединяет этот домен с пониманием домена в широком смысле.
Ну нет же конечно, одного названия и картинок не достаточно.
Да, в тексте описано направление подключения классов. О том, что обращение к модулю опирается на application, а он на domain, только в таком порядке.
Про инверсую зависимостей совсем грустно с точки зрения технического специалиста, рекомендую всетаки вам прочитать книжку "чистая архитектура" Роберта Мартина
Потом можно Мартина Фаулера, но у него шрифт более мелкий и чтиво потяжелее ;)
Интересно как так получается что по заверениям СТО ваша компания выпустила больше сотни "отличных" инженеров, но которые, по всей видимости, не знают что такое инверсия зависимости :)
Ну и кстати, такой подход будет работать на проектах с простой бизнес логикой, потому что при таком подходе к организации кода не о каком моделировании бизнес процессов в домене речи идти не может)
У вас код разбит по модулям, которые в свою очередь содержат "луковичную" архитектуру.
Луковичную я беру в кавычки потому что не до конца понимаю вашу интерпретацию, убрать 1 слой, чтобы добавить его в доменный, ну и 3 слоя внутри 1 слоя не выглядят по луковичному)
Как видится мне - разделением на модули вы получаете дублирование кода, неконтроллируемое, команды могут даже не знать что пишут в принципе одно и тоже. Но что более важно - запрос к бд, у вас на каждый юзер кейс сколько обращений к базе? У каждого модуля свои обращения? А как на счёт сложных join запросов?
Тут кстати назревает организационный вопрос, разве много бизнес задачи которые затрагивают 1 конкретный модуль? Большинство задач превращается в тим билдинги?
очередность подключения (Use) классов-зависимостей должна быть строго последовательной и направленной внутрь модуля. Он должен зависеть только от самого себя, и при этом внешние слои — только от внутренних.
Я очень сильно надеюсь что вы здесь не про инверсию зависимостей))))
Мне кажется у вас в статье противоречие:
Во-первых, остаются общие зависимости. Например, сам фреймворк и часть библиотек подключены для всех модулей. При необходимости вынести модуль в отдельный сервис он поедет вместе с этими зависимостями.
Дополнительно система стала готова к дальнейшему развитию. Любой модуль при необходимости можно вынести в отдельный сервис без радикальной переработки.
Конкретный пример с какими-то абстрактными уточнениями)
По каждому уточнению принимать решение конкретному человек по конкретному проекту, а не демогогию разводить, не один паттерн не даст вам ответы на такие вопросы, причём тут вообще репозиторий)
Если у вас что-то умеет база или не умеет вы можете переносить обработку данных хоть в код проекта хоть в базу. Если sql - больше логики в базе (сложные запросы) если nosql - больше обрабатывается кодом (более бедная модель данных)
Репозиторий помогает направить зависимости и отделяет код бизнес логики от кода получения данных)
Вас явно пытались обмануть, потому что репозиторий разделяет код и задаёт правильное направление зависимостям, а не экономия на переходе с sql на nosql, но в свою очередь такая возможность тоже имеется
Про сигнатуру это ваши заморочки которые я до сих пор не могу понять) Если вы в репозитории отдаёте просто что вам вернула ОРМ, это не проблема репозитория как паттерна)
В том и проблема, что “элегантно и удобно” на практике не получается
Не говорите за всех, у кого-то получается, в книгах куча примеров.
Вы интерфейсом закладываете потребности вашего получателя данных (домен, агрегат как у автора), а не детали реализации sql, nosql. Детали никак не влияют на абстракцию)
GetById в sql и nosql очевидно имеют разную реализацию, но интерфейс репозитория содержит сигнатуру GetById
новую реализацию написать мало, под новый стор переписываются сами запросы
А что для вас реализация репозитория если не воплощение запроса в его конкретном виде?) Да и возвращаемые значения должны быть по сигнатуре одинаковые...
Поэтому в решении мы и спускаемся к драйверу напрямую. Никакого "Mongo → никто → Mongo": база умеет всегда, а нам мешает только обобщённый контракт над ней.
Извините за такой вопрос, если что, а вы комменты пишите и читаете с нейронкой вместе или мне показалось?)
Ну если честно дженерик репо это просто сахар для разработчика, должно быть очевидно что crud это не все чем должен заниматься источник данных)) И это очевидно не все что нужно вашим агрегатам))
А вообще, я просто пытаюсь разобраться - что и для чего вы написали :) Раз уж архитектура это и моя работа)
Если честно моё мнение что в ИТ очень многие решения принимаются эмоционально, некий массовый психоз проплаченный гигантами индустрии (микросервисы, джаваскрипт). Необходимо воздействовать не только на мозг инженера, но и на людей которые принимают финансовые решения. Поэтому микросервисы и джаваскрипт должны быть везде и под сомнения их ставить не должно быть принято)
P.S. перечитал ваш комментарий - а ведь действительно, по итогу сам разработчик по той или иной причине становится лоббистом всяких странных решений)
Идея до разработчика часто доходит не в изначальном смысле (собственное погружение в проблемы и изучение), а уже переваренная индустрией
Вот и получаеются микросервисы с луковичной архитектурой)
Или вот кэш, я думаю знающие люди понимают как сложно сделать прослойку кэша для бд. Сколько раз я видел redis которые по факту стоит в стороне от системы (торгует лицом, осваивает бюджет) а по бумагам редис чуть ли не из главных хранилищь, когда я указал на это тимлиду и начальнику департамента, что подрядчик редисом просто бабки в договоре отмывает, как же на меня тогда накинулись мои же коллеги)) Какое-то массовое помещательство)
Спросонья рассмешили меня))
Интересно конечно почему не стоит очередь из перформеров в компанию "сил добра", чтобы пробиться через кучу собеседований и начать за 100-200к обучать тимлидов инверссии зависимости))
Think about вроде фраза такая есть)
Кто мне не верит - попросите автора вынести слой домена из приложения, замокать его и протестировать бизнес кейсы.
А я вам сразу скажу что здесь так не получится, здесь нет никакого домена, здесь куча модулей со "слоеной" архитектурой где лежит папочка "домен", это все что объединяет этот домен с пониманием домена в широком смысле.
Ну нет же конечно, одного названия и картинок не достаточно.
Про инверсую зависимостей совсем грустно с точки зрения технического специалиста, рекомендую всетаки вам прочитать книжку "чистая архитектура" Роберта Мартина
Потом можно Мартина Фаулера, но у него шрифт более мелкий и чтиво потяжелее ;)
Флоу бау уау юпи ёй юпи ей
Интересно как так получается что по заверениям СТО ваша компания выпустила больше сотни "отличных" инженеров, но которые, по всей видимости, не знают что такое инверсия зависимости :)
Ну и кстати, такой подход будет работать на проектах с простой бизнес логикой, потому что при таком подходе к организации кода не о каком моделировании бизнес процессов в домене речи идти не может)
У вас не луковичная архитектура.
У вас код разбит по модулям, которые в свою очередь содержат "луковичную" архитектуру.
Луковичную я беру в кавычки потому что не до конца понимаю вашу интерпретацию, убрать 1 слой, чтобы добавить его в доменный, ну и 3 слоя внутри 1 слоя не выглядят по луковичному)
Как видится мне - разделением на модули вы получаете дублирование кода, неконтроллируемое, команды могут даже не знать что пишут в принципе одно и тоже. Но что более важно - запрос к бд, у вас на каждый юзер кейс сколько обращений к базе? У каждого модуля свои обращения? А как на счёт сложных join запросов?
Тут кстати назревает организационный вопрос, разве много бизнес задачи которые затрагивают 1 конкретный модуль? Большинство задач превращается в тим билдинги?
Я очень сильно надеюсь что вы здесь не про инверсию зависимостей))))
Мне кажется у вас в статье противоречие:
Да да, знаю знаю, читали бы книги айтишники и вникали, не утонула бы индустрия в микросервесном психозе)
Под "и все" я имею ввиду что бизнес логика не затрагивается, а пишется только обёртка для данных и все))
Не самый сложный, не значит что он лёгкий или вообще средний)) Вроде такое должно быть очевидно
Экономия по сравнению с чем? Хотите сказать что в неструктурированном коде менять источники данных так же как менять их с репозиторием?)
Тут же речь про паттерн, вопрос про маппер был скорее с сарказмом))
По существу я от вас ничего не увидел, интерфейс и какие-то рассуждения вокруг него которые нужны конкретно вам)
А мне, если честно, все понравилось :)
Я вам отвечал на конкретную фразу, поэтому не надо передергивать и говорить за меня. Темболее что это супер легко я не писал.
Я уже вам ответил на ваши "конкретные" вопросы, их нужно решать по факту
Быстрых ответов на сложные вопросы вы не получте, не тут, не из книг, только от нейронки наверное
Но я бы рекомендовал книги :)
Конкретный пример с какими-то абстрактными уточнениями)
По каждому уточнению принимать решение конкретному человек по конкретному проекту, а не демогогию разводить, не один паттерн не даст вам ответы на такие вопросы, причём тут вообще репозиторий)
Если у вас что-то умеет база или не умеет вы можете переносить обработку данных хоть в код проекта хоть в базу. Если sql - больше логики в базе (сложные запросы) если nosql - больше обрабатывается кодом (более бедная модель данных)
Репозиторий помогает направить зависимости и отделяет код бизнес логики от кода получения данных)
Вас явно пытались обмануть, потому что репозиторий разделяет код и задаёт правильное направление зависимостям, а не экономия на переходе с sql на nosql, но в свою очередь такая возможность тоже имеется
Про сигнатуру это ваши заморочки которые я до сих пор не могу понять) Если вы в репозитории отдаёте просто что вам вернула ОРМ, это не проблема репозитория как паттерна)
Не говорите за всех, у кого-то получается, в книгах куча примеров.
Вы интерфейсом закладываете потребности вашего получателя данных (домен, агрегат как у автора), а не детали реализации sql, nosql. Детали никак не влияют на абстракцию)
GetById в sql и nosql очевидно имеют разную реализацию, но интерфейс репозитория содержит сигнатуру GetById
А что для вас реализация репозитория если не воплощение запроса в его конкретном виде?) Да и возвращаемые значения должны быть по сигнатуре одинаковые...
И DI тут не причём...
Извините за такой вопрос, если что, а вы комменты пишите и читаете с нейронкой вместе или мне показалось?)
Ну если честно дженерик репо это просто сахар для разработчика, должно быть очевидно что crud это не все чем должен заниматься источник данных)) И это очевидно не все что нужно вашим агрегатам))
А вообще, я просто пытаюсь разобраться - что и для чего вы написали :) Раз уж архитектура это и моя работа)
Мне кажется это частая ошибка в понимании репозитория.
Если у вас данные абстрагированны репозиторием, это не значит что вы можете просто в проекте переключать источники данных как захотите.
При необходимости сменить или добавить источник данных - пишем новую реализацю репозитория, подставляем в алиас новый репозиторий и все)
По моему очень элегантно и удобно)
Ну и по реализации репозиторий явно не самый сложный паттерн)) Но один из самых важных, как по мне