Вы в пример приводите модели на чтение. Тут действительно ничего не нужно абстрагировать. Возвращайте просто модель на чтение и все, в ней нет никакой логики.
Давайте возьмем в пример расчет скидок, если угодно. Или каскадирование платежа в различных платежных провайдеров.
Отделяют обычно ради тестируемости. Интеграционное тестирование в масштабах большой кодовой базы становится очень дорогим.
Даже если у вас БД доступна из любого места в приложении вам придется решать как приводить агрегат в согласованное состояние и не забыть нужные поля изменить.
Если вы с такой проблемой не сталкивались, значит ваши бизнес-процессы позволяют вам держать бизнес-логику небольшой.
Проблемы организации логики зависят от домена, а не языка. Если у вас будет сложная доменная логика, вы будете ее разбивать на составные части вне зависимости от языка. Поэтому слои абстракции будут появляться.
Вопрос на сколько они будут дырявые? Использование подходов из других языков может помочь понять в какой момент абстракция даст течь и сколько будет стоить её поддержка.
Например, это позволяют делать обработчики событий BeforeSave ORM gorm и ent. Но такое поведение является непривычным для большинства разработчиков и требует отдельного упоминания на онбординге.
Да достаточно, когда сервис маленький. Когда сервис большой и народу в команде много, то люди начинают повторять текст ошибки, за этим приходится следить. Кроме того по логам или сентри становится невозможно построить аналитику по наиболее частотным ошибкам
Не для всех приложений. Выход из приложения будет только в случае простеньких cli утилит. А паника, если ошибся разработчик и нужно срочно бежать и править багу (если вы, конечно, не БД где иногда кидают панику, чтобы пропустить все if'ы).
Предположим ошибка возникает в репозитории при запросе какой-то сущности. Какая информация была бы полезна? ID сущности, возможно какие-то фильтры, если есть. Отлично, это есть всё в параметрах метода. Для этого добра можно создать свой тип ошибки.
А как в месте возникновения ошибки получить request-id, user-id и т.д.? Те переменные, которые совсем не нужны в параметрах функции репозитория, но которые важны? Пробросить их через контекст один из вариантов. И это нужно только в том случае, когда мы на верхних слоях не оборачиваем ошибку. Если оборачиваем, то можем информацию добавить и там.
А потом смотришь на код неВась и удивляешься, почему неВася забыл про обратную совместимость, не учел что система распределенная и счетчики в памяти не будут работать корректно и т.д.
Знать != делать. Одно дело понимать как все приложение целиком работает и в каком из компонентов может быть проблема, к кому идти с этой проблемой. Другое настраивать с нуля с соблюдением best practice.
Да и работа программиста не текст набирать, а решения принимать.
Постараюсь сделать, но увы недельки через 2 только.
Вы в пример приводите модели на чтение. Тут действительно ничего не нужно абстрагировать. Возвращайте просто модель на чтение и все, в ней нет никакой логики.
Давайте возьмем в пример расчет скидок, если угодно. Или каскадирование платежа в различных платежных провайдеров.
Отделяют обычно ради тестируемости. Интеграционное тестирование в масштабах большой кодовой базы становится очень дорогим.
Даже если у вас БД доступна из любого места в приложении вам придется решать как приводить агрегат в согласованное состояние и не забыть нужные поля изменить.
Если вы с такой проблемой не сталкивались, значит ваши бизнес-процессы позволяют вам держать бизнес-логику небольшой.
Проблема не только в мапперах. Придется делать геттеры / сеттеры, чтобы скрыть поля.
Проблемы организации логики зависят от домена, а не языка. Если у вас будет сложная доменная логика, вы будете ее разбивать на составные части вне зависимости от языка. Поэтому слои абстракции будут появляться.
Вопрос на сколько они будут дырявые? Использование подходов из других языков может помочь понять в какой момент абстракция даст течь и сколько будет стоить её поддержка.
Да, это отличный вариант
Например, это позволяют делать обработчики событий BeforeSave ORM gorm и ent. Но такое поведение является непривычным для большинства разработчиков и требует отдельного упоминания на онбординге.
Да достаточно, когда сервис маленький. Когда сервис большой и народу в команде много, то люди начинают повторять текст ошибки, за этим приходится следить.
Кроме того по логам или сентри становится невозможно построить аналитику по наиболее частотным ошибкам
В большинстве приложений ошибку пробросят на верх в слой контроллеров (если мы про какой-то сервер) и там отдадут клиенту
Не для всех приложений. Выход из приложения будет только в случае простеньких cli утилит. А паника, если ошибся разработчик и нужно срочно бежать и править багу (если вы, конечно, не БД где иногда кидают панику, чтобы пропустить все if'ы).
Предположим ошибка возникает в репозитории при запросе какой-то сущности. Какая информация была бы полезна? ID сущности, возможно какие-то фильтры, если есть. Отлично, это есть всё в параметрах метода. Для этого добра можно создать свой тип ошибки.
А как в месте возникновения ошибки получить request-id, user-id и т.д.? Те переменные, которые совсем не нужны в параметрах функции репозитория, но которые важны? Пробросить их через контекст один из вариантов. И это нужно только в том случае, когда мы на верхних слоях не оборачиваем ошибку. Если оборачиваем, то можем информацию добавить и там.
А чем реализация Pub/Sub от watermill не понравилась?
А потом смотришь на код неВась и удивляешься, почему неВася забыл про обратную совместимость, не учел что система распределенная и счетчики в памяти не будут работать корректно и т.д.
Знать != делать. Одно дело понимать как все приложение целиком работает и в каком из компонентов может быть проблема, к кому идти с этой проблемой. Другое настраивать с нуля с соблюдением best practice.
Да и работа программиста не текст набирать, а решения принимать.
Как мне кажется с такой структурой получилось тоже самое, что было без DI.
А вот если каждый компонент завернуть в модуль от uber.fx, то получается красиво при большом наборе компонент.
Если приложение небольшое, 10-12 компонентов, то можно обойтись без DI, потратив чуть больше времени на начальное написание компонента.
Добавление слишком большой сложности ради небольшой экономии времени.
Обычно используют инструменты, решающие конкретные задачи, а не комплексные фреймворк.
Для проблем, которые автор статьи описывает, фреймворками или библиотеками пользоваться не принято.
injector.Bind - прям Guice веет из Java
Odoo как аналог УТ, возможно КА (без бухгалтерии)
jmix как аналог платформы.
МойСклад - конкурент розницы и УНФ.
Ну и различные CRM, конечно.
Спасибо огромное, что выложили на github!
Тоже задался этим вопросом, и вот что удалось найти: