Дмитрий Анисов - DDD на практике

[@Elijah-xe2he]

Если я правильно понял, в представленной структуре слой application зависит от infrastructure. В луковой и подобным архитектурам как раз наоборот infrastructure должна зависеть от application. Полагаю, автор доклада изменил направление зависимости, чтобы было проще дергать инфру из application не плодя лишние интерфейсы? Тогда это неправильно называть луковой архитектурой.

[@mtk6188]

Нет, инфраструктура на то и инфраструктура, чтобы стоять особняком: в ней находятся детали реализации типа "как отправить емейл", или "как ходить в базу" и т.п. В аппликейшен лейере вы описываете конкретные бизнес юзкейсы, например, достать из репозитория объект, запустить на нем доменную логику, отправить емейл после и т.д.

[@Elijah-xe2he]

@@mtk6188 я понимаю, что размещается в инфре, что в app слое, что в доменке. Нарушать зависимости слоев неправильно, если хотите луковую/чистую/хексагональную архитектуру. Никто не запрещает из app слоя обращаться к репозиторию, на то и придуманы интерфейсы и IoC.

[@alexandrfolomkin9380]

Выносить интерфейсы в go в отдельный пакет - такое себе решение, сразу оказывается что интерфейс становится публичным, а значит может где-то использоватся - а это уже протекание абстракций. Интерфейсы должны объявляться в том же месте где и используются Использовать функцию init - это антипаттерн - неявное выполнение кода, тем более с if. Для настройки лучше использовать репозиторий с несколькими реализациями. application и service - граница какая-то вялая между ними Короче, питонист пришел в гошку и наводит шорох

[@asdfsavs6846]

Вопрос по поводу интерфейсов. Допустим есть интерфейс репозитория. Репозиторий нужно использовать в нескольких местах (сервисах). Что вы предлагаете? Копи-пастить интерфейс в два места?

[@maoshultz1731]

Там где вы его реализуете

[@Elijah-xe2he]

Интерфейсы на то и нужны, чтобы быть публичными ) Чтобы внешний код был зависим от контракта, а не от реализации. Если интерфейс приватный и лежит рядом с реализацией, в чем тогда его смысл? Сам по себе публичный интерфейс не создаёт проблемы протекания абстракций. Проблему создают разработчики данного контракта, пытаясь сделать его универсальным или "гибким". Если контракт заставляет реализации знать о деталях внешнего окружения - абстракции текут. Если контракт заставляет внешнее окружение знать о деталях реализации - абстракции текут. Делайте строгие полные контакты и не будет проблем протечек.

[@f0rzend59]

Это какой-то перезалив? Как будто я уже слышал этот доклад...

[@Bunkerniy_Gadenish]

Слышу «это база или лучшие практики» сразу посылаю скуфа накуй