Есть у кого пример небольшого реста. Хочу посмотреть, как код

организовываете.

На сколько вообще обоснована чистая архитектура? Как часто у вас бд менять приходилось, роутер или мэил клиент? По мне так бизнес логика меняется чаще.

https://github.com/evrone/go-clean-template

Естественно, бизнес-логика меняется чаще Вопрос то в чём?

Вопрос в том, зачем тогда чистая архитектура? Она предполагает, что бизнес логика - фундамент и он не должен меняться, а меняться будут зависимости

Неправда

После добавления сущности метода или поля надо будет изменить реализацию метода у интерфейса, контактирующего с бд, изменить/добавить usecase, поменять обработку в хэндлере. Также надо будет менять все интерфейсы, если например новый метод появился или аргумент функции поменялся, помимо изменений в реализациях. Тогда уж проще без интерфейсов вообще обойтись, меньше придётся кода писать. Да и не будет возникать вопросов типа «что делать, если у меня интерфейс UserRepository появляется в нескольких usecase», дублировать объявление интерфейса(ведь в го интерфейс принято объявлять там, где он используется)? Но тогда ещё больше менять придётся при изменении логики.

https://habr.com/ru/post/269589/ Прочитайте начало статьи хотя бы, там сказано, зачем нужна чистая архитектура

Я использую чистую архитектуру, всё удобно и красиво, все разделено на слои и каждого слоя своя работа. Элементарно даже, проще ориентироваться по коду.

Ну вот собственно и вопрос. Стоит ли независимость от бд и внешних библиотек дублирования и дополнительного кода? Решили поменять mongo на sql, все равно придётся код для sql писать да и какова вообще вероятность, что это произойдёт?

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

А тесты вы писать как будете?

Да, вот единственное преимущество, которое я вижу. Но очень классно подстраивать код, чтобы было удобнее тесты писать. В крайнем случае можно и фейковую бд создать и гет запрос сделать.

А на ci/cd тоже руками код проверять будете?

А если ваш сервис отправляет запрос на другой сервис, будете оба сервиса запускать, чтобы только один протестировать?

Также как с http.Get такие моменты можно оборачивать. Интерфейс DataGetter в нем функция Get, которая возвращает []byte. То есть оборачиваем конкретно этот метод и тестируем. И ещё, если не запускать сервис второй, то все равно не получится в полной степени провести тесты. Вдруг что-то изменилось на сервисе? Или какой-то кейс хитрый.

То есть, чтобы не использовать интерфейсы вы предлагаете ввести другие интерфейсы?

Нет. Я предлагаю не использовать интерфейсы везде подряд, а только там, где это необходимо для тестирования. Например оборачивать бд в интерфейс не стоит, потому что вряд ли она изменится.

1) а вдруг изменится? 2) для тестов, независимых от бд

Какой у вас опыт коммерческой разработки?

А я предлагаю использовать интерфейсы везде где можно) Почему? Потому что если этот проект не на 1 день. То потом вы не будете думать как придумать костыль для тех то данных.

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

Никакого

Спасибо за совет )