@antonikucherov тут такой момент. Clean наверняка будет лучше, когда разработчики действительно понимают куда ее прилепить. Я лично пока не понимаю, что она даст в с равнении с обычной слоистой архитектурой. Возможно, масштаб проектов не тот.

Поэтому вопрос к той архитектуре, которую я кидал в моем шаблонном проекте. С какими сложностями я столкнусь в ней? Потому что такая же архитектура используется в проекте, где юзкейсов штук 100+. И помимо базы еще очередь для лайв апдейта контента и прочее. Вроде сложности в поддержке нет. Но может я что-то упускаю и что-то можно было бы сделать проще.

Запихнуть в класс этот объект. Только с обьектом транзакции так не выйдет. С пулом соединений к БД проблем нет

Разница в том что средствами сдк у вас будет вдвое больше кода

почему не выйдет?

И сравнивать решения где под капотом уже миллион строк и чистые - необъективно ни на йоту

а зачем мне брать ждк только и мудохаться?

ну ведь для примера го взял же

Действительно
Вам так весело набрасывать видимо, но возвращаясь к вашим же словам - стоит посмотреть по сторонам и внезапно окажется, что можно лучше и короче, чем в подробном примере

Сейчас я делаю как: вызываю метод Transaction, которая возвращает интерфейс storage и в underlying структуре вместо пула коннектов транзакция идет. И методы дёргаются с этого новосозданного обьекта

Если у нас несколько структур под свои сущности, то мы должны открыть транзакции в каждой структуре, получается. И если у нас задействованн несколько сущностей, например, 3, это 3 транзакции.

Обьективно - тк это подход Го  как мы тут обсуждали пару часов назад. Что каждый лепит свой велосипед и потом вот такой код приходится поддерживать. Погуглите что то подобное про джаву и там будет почему то примеры со спрингом а не на сырой джаве с локами туториалы.

Чтобы ответить на этот вопрос предметно, надо определить для начала, что такое "слоистая архитектура" и, что вы под ней понимаете?  Clean это и есть вариант слоистой архитектуры, при этом она достаточно четко определена. Там рассказано что от чего может зависеть а что не может, и приведены примеры, почему именно так.

потому что в джава мире никому в голову не придет такое писать и выкладывать как пример чистой архитектуры.

Под слоистой в данном случае имею ввиду то, что у меня в примере

коллега, а сформулируйте свой тезис? а то как-то я не понимаю, за что вы топите

мне не весело, я просто удивлен тем что говорят что на джаве надо написать больше кода чтобы выразить то что можно на Го и тем что нормально метод по заполнению данными с бд сделать на 50 строк.

Сравнивать 1 пример где все понятно и подручными средствами реализовано, и 2 где все наоборот - не наброс?)

Никто не спорит, что в джаве есть куча сахара. Что вы доказываете?

мой поинт что Джава не так уж плоха как ее малют, что Го не так уж хорош. И что под каждую задачу стоит брать свой язык и что надо понимать где конкретный язык сделан хорош а  где можно сделать лучше.

И никто не заставляет пилить велосипеды
Полно решений готовых если поискать. Другое дело, что вам и кажется непривычным, что в случае с го это достаточно просто чтобы не искать

Почему разные хранилища не могут использовать одну транзакцию?