Clean Code Architecture in Golang
Начал изучать реализацию Clean Code Architecture в Golang, и наткнулся на 2 варианта. Код в обоих выглядит одинаково, однако организация пакетов отличается. Выглядят они примерно так:
Вопрос: Как все таки лучше? Какие различия у подходов? Плюсы? Минусы?
Ответы (1 шт):
Первый способ хорош для маленьких монолитных проектов, в которых не предполагается значительное расширение набора функций. Есть сервис 1 и сервис 2, и баста. Тогда можно декомпозировать сервис на два сервиса, обработчик на два обработчика и репозиторий на два репозитория. Всё наглядно. Но при увеличении числа сервисов усложнится поддержка декомпозиций. Обязательно начнутся миграции кода из сервиса в сервис, с которыми нужно параллельно мигрировать обработчики и репозитории. После пяти-семи сервисов захочется изолировать не по функционалу сервис/обработчик/репозиторий, а по компонентам. То есть второй способ.
Второй способ хорош для тех проектов, в которых предполагается разработка большого количества компонентов. Все компоненты одинаково структурированы и независимы друг от друга. Я рекомендую сразу приучаться делать именно так.
Единственное, меня смущает корневой пакет internal - как планируется получать доступ к методам из этих пакетов?