Я Вам всячески намекаю, что описанное решение не универсально и имеет ограниченную область применения
Первое предложение в этом материале: Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.
Концепция проста и незатейлива - "запилил" ровно то и ровно так, как было в ТЗ и давай до свидания до следующего тендера на развитие ИТ-системы.
Если все так делают, не значит что Вы должны. По крайней мере Я делаю не так. Но вот кто так делает, это многое о них говорит, как о профессионалах и людях в целом.
Автор молодец, что самостоятельно придумал и удачно внедрил идею
Спасибо. Ещё не внедрил, в процессе. Я скорее не придумал, а просто формализовал то, что вижу вокруг и чего не вижу в трендах по менеджменту.
Что можно сделать лучше
Как будут итоги внедрения второй материал выйдет, со ссылкой на этот.
Спасибо, да теперь четко вижу, это матричный подход, только не между разными отделами типа бухгалтерия, продажники и т.д. А внутри ИТ отдела, предварительно побив его на функциональные части (центры компетенций)
Банк не производит ИТ-продукт, вернее не продает его на рынке, у него ИТ направлено на обеспечение финансовых услуг
Каждый банковский продукт, особенно для бизнеса, это обычно отдельное IT решение, то есть с точки зрения разработчика - продукт, по крайней мере в тех банках, с которыми работал.
Далее Вы там накидали чего-то не понятно к чему относящемуся. PM должен стоять горой за свой продукт, а не за людские ресурсы. То о чем Вы говорите, это когда почему то PM занимается не своей работой. И главное чтобы продукт выполнял свои функции и работал, а не чтобы за продуктом было закреплено как можно больше народа, которому нужно платить зарплаты и которую нужно менеджерить.
Фирма-аутсорсер не производит ИТ-продукт
А результатом заказной разработки что является? И не надо никем жонглировать, каждый выполняет свои функциональные обязанности.
На этом спринте команда напилит фичу в Oracle Siebel CRM, на следующем ...
Ну так это о чем Я и говорил, что предлагал. Вместо того чтобы кто-то был завязан на CRM, кто-то на ERP, кто-то ещё на чем то. Сейчас во многих компаниях именно такая привязка к одному продукту.
А в Яндексе хоть каждый день меняй команды между поисковиком и такси.
Нет, вообще не так, там жесткая завязка под один продукт, у каждого продукта свой тулинг, свои либы, стандарты и т.д. Нельзя вот так взять и перейти из поиска в такси и даже из такси в доставку еды.
Как говорится, one size fit them all. Везде библиотечный подход, типовые кубики.
Вот как раз таки мало где. О чем и речь.
Рекомендовано к использованию в крупных компаниях.
Более чем реально. Вести продукт или писать интеграции? О какой позиции речь? Тимлид или сеньер Я полагаю? Так они сами не пишут, они рулят кучей интеграций, решают какие то архитектурные вопросы, как это всё упаковать, универсиализировать и т.д. Если на таком примере - поддерживать 2 старых продукта или заниматься продумывать интеграцию с разными сервисами. По мне так второе звучит интереснее.
Дэк о чем и речь, если написали как есть, запустили и забыли так и будет. А если часть функционала пишется командой, которая на этом функционале специализируется, она оборачивает его в библиотеку и поддерживает. Вот с этим опыт предостаточно и работает оно отлично.
Это редко работает по куче причин
В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности. Оборачиваете бойлерплейт в библиотеку, оборачиваете общие функциональности в библиотеку, используете. Вышла обнова - обновили библиотеку, обновили сервисы. Никто не говорит свой nest.js с нуля написать. Микросервисы общие нельзя делать потому что вход выход несколько отличается, разные продукты и правообладатели, а вот использовать общую библиотеку в 2 сервисах совсем другое дело.
Есть два варианта
А есть вариант посадить аналитика, разбить проект на сущности и функциональности, посмотреть что уже реализовано и MVP составить из того что есть среди реализованных функциональностей (если требуется быстрый запуск, что происходит в 90% случаев, всякие гос контракты и т.п.). А потом параллельно допилить в разных командах части системы.
Сделать фичу своей командой
Если речь идёт исключительно о фиче внутри продукта - смотрите к чему фича относится функционально и в той команде её делают. Не понимаю какие проблемы у Вас с постановкой, но они явно есть, потому что не пообщеал, а вот задача в спринте и цель спринта, взял и сделал.
создавая библиотеки, вы создаете зависимости
Проекты в любом случае, если это не какие то велосипеды основаны на библиотеках, которые НАДО обновлять. И судя по всему Вы этого не делаете?
все время держать "в тонусе"
Ну так если 5 лет заниматься одним продуктом, о каком тонусе идёт речь? А вот если это разные продукты, но при этом ты делаешь что-то именно в своей компетенции, с тонусом проблем нет. К тому же можно перейти в другую команду с другими компетенциями и поднять тонус там.
Как только команда типа просто делает заказы
Смотря речь о ком, джуны мидлы 99% класть хотели на все нюансы продуктов, дайте четкую задачу, мы сделаем. А у сеньеров и лидов в развлечениях разные продукты, шлифование библиотек, брейнштормы как правильно сделать что-то чтобы можно было зашить в библиотеку и переиспользовать на других проектах
Что лучше? - "ты отвечаешь за интеграции" или "вот тебе 8 продуктов, одни написаны 5 лет назад, другие вот в процессе написания, изучай потому что написаны с разными подходами и вот тебе пачка задач во всех продуктах по чуть чуть в разных частях и ты не должен ничего сломать." Учитывая что у тебя большая часть команды мидлы, периодически приходят джуна, а сеньеров штук 5 и они заняты другими продуктами
Каша с задачами решается четкими целями в спринте. У каждой функциональной команды свой руководитель. А ПМ-у да, нужно будет с них спрашивать. Плюс команды работают уже по проработанной аналитиками бизнес логике. На низовом уровне ничего не изменится.
При уходе тимлида одной команды появляется риск того что пострадают все продукты организации
Не соглашусь. Это так, когда тим лид отвечает за продукт. А когда тим лид отвечает за функциональную область, он прорабатывает эту область со всей командой и вся команда примерно всё знает, потому что ей не нужно распыляться на знание всего продукта
Задача ПМ-а и аналитика разобраться в продукте с точки зрения бизнеса и все знания задокументировать. То есть бизнес процессы и сущности будут задокументированы и понятны всем кому нужно, а разрабам это и вовсе не нужно, особенно джунам и мидлам, которые в основном чисто механическую работу делают.
Ну и тут писал
Bus фактор не такой болезненный
Полностью он конечно же не уйдет. Тут вопрос выгоды, что проще - найти пм-а или сеньера?
Можно пример? Потому что RnD может быть продуктовый, что обычно не нужно, это задача менеджмента и аналитиков понять боль бизнеса. А может быть RnD функциональный, который целиком уходит в какую то из команд, прорабатывается и возможно внедряется и на других продуктах.
они теряют фокус
Документация, спринты, цели спринтов помогают четко понимать что мы делаем и куда идём
Устройство ИТ сильно отличается от приведенных Вами схем
Можно пример? Потому что Я вижу размышления только про продуктовый подход, который висит из всех щелей откуда хоть что-то можно услышать про менеджмент. Яндекс, майкрософт, гугл, всякие банки, операторы связи и т.д. (см. любую конференцию)
Большие компании
Тут скорее про количество продуктов или их величину
ни одного измеримого показателя "лучше/хуже" при сравнении подходов, а так же статистики
Потому что подход на стадии внедрения. Ну сразу могу сказать, на 8 продуктов вместо 8 команд продуктовых из разномастных спецов, нужно 6 функциональных команд с другим подходом. Плюс планируется ещё несколько продуктов, на которые не надо нанимать новую команду, а функционал поделить и реализовать имеющимися командами.
Рост числа продуктов влияет на количество людей, так как банально растет нагрузка. и с этим сделать НИЧЕГО нельзя. Просто тупо стало больше и все
Просто тупо - это ключевое
Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет двигаться. Отсюда и заявления типа Устаревание кода - это просто данность, сразу четко виден подход х%як х%як, в продакшн и забыли.
Как связано глобальное состояние и транзакции?
Глобальное состояние это то что хранит сервер в себе, вне зависимости от текущего запроса, транзакция происходит по запросу и в рамках него. Чем транзакционность на уровне бизнес процесса отличается от транзакционности внутри домена? И как это вообще может быть связано с глобальным состоянием?
Ну и логика (отката)транзакций — совершенно не бизнес-логика.
Совершенно верно, потому что бизнес логика лежит на уровне домена. А вот транзакционность и откат транзакции относится к бизнес процессу. Внимательнее на схему посмотрите, она вроде простая, хотя видимо не очень.
Методологически она скорее вредна тем, кто подумает «так вот как DDD делать надо».
Чем именно? Конкретный пример, что тут не так. Или Вы пустозвон уважаемый?
Большие графы объектов похоронят вашу производительность при таком подходе.
При чем тут большие графы и как они связаны с конкретно этой архитектурой? Я извиняюсь Вы вообще программист? Я уверен, Вы вообще не понимаете то, о чем пишете.
В этом примере также типичные антипаттерны типа анемичной модели, из-за чего логика работы объекта полностью переезжает в ваш слой «бизнес процессов» и появляется low cohesion со всеми вытекающими, вследствие чего смысла в отдельных доменных объектах практически не остаётся.
Теперь Я точно уверен что Вы не понимаете о чем пишете. Просто сотрясаете воздух терминами, в которых не разбираетесь.
Тем, кто будет читать данный комментарий: просто прочитайте про анемичную модель и сравните с тем, что пишет данный индивид выше.
Вы очень поверхностно поняли смысл DDD и почему его авторы рекомендуют именно те подходы, которые помогают делать поддерживаемый код при автоматизации сложных бизнес процессов. Если вам всё это влом понимать — так не надо себя мучать.
А, Вы предлагаете поступить как Вы — "не понимаю, ну и ладно, буду кидаться сложными терминами в комментариях". Нет, спасибо.
Сделайте CRUD и если оно заработает для вашей задачи — ну и замечательно.
Ну оно и видно, что Вы сложнее CRUD-а в своей жизни никогда ничего не писали.
В заключение:
Я попросил конкретных примеров и советов, Вы начали оскорблять, уклоняться от ответа, и уходить ещё глубже в теорию, которую сами не понимаете.
С Вами всё понятно, тут нечего обсуждать, лучше идите пару приложений напишите, опыта наберитесь.
Объяснили понятно, спасибо.
По моему DDD не совсем про это. Домены обособляются не потому что "так надо", а потому что каждый домен — это большой пласт нюансов, который по хорошему должен разрабатываться отдельной командой, но при этом чтобы был понятен другим и его можно было легко протестировать и использовать.
А что мешает задублировать внутрянку бизнес процесса? Это даже не будет нарушением DRY, потому что бизнес процесс может измениться (сейчас он похож на другой, а потом станет не похож) или отличаться маленьким нюансом, из за которого придется дочерний бизнес процесс переписывать и учитывать этот нюанс, а это уже приводит к неоднозначности ответа от бизнес процесса, что нарушает те маленькие правила, которые Я для себя вывел.
К тому же если так сгущать краски, можно любую архитектуру "запороть", важно соблюдать баланс. Я например не могу придумать сценарий, где "придется" городить супер бизнес процесс.
По поводу предполагаемого метода createPartner, это сработает, пока нет каких то особенностей. Но как только какая то часть внутри усложнится метод createPartner превратится в 100-строчный код с кучей if-ов, уже видел неоднократно.
Речь идёт не про то чтобы код был красивым после написания приложения, а про то чтобы его можно было поддерживать и расширять, потому что бизнес меняется, условия меняются и надо быстро и удобно развивать приложение. Это кстати огромная беда, что разработчики думают только про момент запуска приложения и совсем не думают о последующих этапах жизненного цикла.
Ещё одной проблемой является тестирование, подмена всех зависимостей в композитных методах — это будет адище.
По поводу сложности приложения — про DDD начинают задумываться после прохождения определенной точки сложности проекта, когда добавление маленькой фичи оборачивается огромным пластом работ. Вы предлагаете метод от сложного к простому, но обычно проект развивается от простого к сложному и появляется необходимость во всём вот этом. Когда есть маленький сервис, конечно DDD, даже в минимальной своей реализации избыточен.
Согласен с критикой.
По поводу инъекций, тут можно нагородить как в Nest-е, но для меня это кажется избыточным, а так да, можно DI полноценный реализовать и не руками внутрь пробрасывать, а через DI.
Да, каждый вышестоящий слой связан с предыдущим, а адаптеры связаны как с предыдущим так и с вышестоящим (на картинке в виде выступов на самом блоке). Но если не брать теоретические модели, то в практике полностью несвязанные сущности сделать либо невозможно, либо овчинка выделки не будет стоить, по сложности. Поэтому есть абстракции в виде адаптеров, чтобы не быть связанным с конкретной БД или конкретным API.
А где Вы тут видите замкнутость? Уже в гексагональной замкнутости нет, потому что добавились стороны, а это уже значит что форма и визуализация неправильно подобраны.
Нету каноничной реализации, есть разные имплементации и то совсем не полные.
Приведите пример хоть сколько нибудь работающего приложения, где операции над сущностями разных доменов не выполняются одновременно? Невозможно реализовать работающий бизнес процесс только внутри одного домена, у Вас в итоге получится один огромный домен.
Я биллинговую систему частично перевел на эту архитектуру, никаких проблем. А модели там раз в 20 сложнее, чем в примере.
Приведите хоть один практический совет по реализации из книги, который не вписывается в эту архитектуру. Я не пытаюсь DDD переиначить, просто вывожу практический опыт в теоретическое поле.
Я и не говорю, что делаю каноничную… Я сделал ту, которая мне сильно упростила работу, при этом соответствует моим критериям "красоты". Делал на основе гексагональной, которую изначально пытался взять за основу, но наткнулся на неудобства.
Первое предложение в этом материале: Сразу скажу, подход актуален для больших компаний с множеством продуктов и соответственно множеством команд, либо для компаний с большими и сложными продуктами.
Если все так делают, не значит что Вы должны. По крайней мере Я делаю не так. Но вот кто так делает, это многое о них говорит, как о профессионалах и людях в целом.
Спасибо. Ещё не внедрил, в процессе. Я скорее не придумал, а просто формализовал то, что вижу вокруг и чего не вижу в трендах по менеджменту.
Как будут итоги внедрения второй материал выйдет, со ссылкой на этот.
Спасибо, да теперь четко вижу, это матричный подход, только не между разными отделами типа бухгалтерия, продажники и т.д. А внутри ИТ отдела, предварительно побив его на функциональные части (центры компетенций)
Каждый банковский продукт, особенно для бизнеса, это обычно отдельное IT решение, то есть с точки зрения разработчика - продукт, по крайней мере в тех банках, с которыми работал.
Далее Вы там накидали чего-то не понятно к чему относящемуся. PM должен стоять горой за свой продукт, а не за людские ресурсы. То о чем Вы говорите, это когда почему то PM занимается не своей работой. И главное чтобы продукт выполнял свои функции и работал, а не чтобы за продуктом было закреплено как можно больше народа, которому нужно платить зарплаты и которую нужно менеджерить.
А результатом заказной разработки что является? И не надо никем жонглировать, каждый выполняет свои функциональные обязанности.
Ну так это о чем Я и говорил, что предлагал. Вместо того чтобы кто-то был завязан на CRM, кто-то на ERP, кто-то ещё на чем то. Сейчас во многих компаниях именно такая привязка к одному продукту.
Нет, вообще не так, там жесткая завязка под один продукт, у каждого продукта свой тулинг, свои либы, стандарты и т.д. Нельзя вот так взять и перейти из поиска в такси и даже из такси в доставку еды.
Вот как раз таки мало где. О чем и речь.
Ну примерно так и делаем, но спасибо за совет.
Более чем реально. Вести продукт или писать интеграции? О какой позиции речь? Тимлид или сеньер Я полагаю? Так они сами не пишут, они рулят кучей интеграций, решают какие то архитектурные вопросы, как это всё упаковать, универсиализировать и т.д. Если на таком примере - поддерживать 2 старых продукта или заниматься продумывать интеграцию с разными сервисами. По мне так второе звучит интереснее.
Не только Вы имеете опыт.
Дэк о чем и речь, если написали как есть, запустили и забыли так и будет. А если часть функционала пишется командой, которая на этом функционале специализируется, она оборачивает его в библиотеку и поддерживает. Вот с этим опыт предостаточно и работает оно отлично.
В компании 15+ продуктов, но все продукты базируются на неком бойлерплейте и имеют похожие функциональности. Оборачиваете бойлерплейт в библиотеку, оборачиваете общие функциональности в библиотеку, используете. Вышла обнова - обновили библиотеку, обновили сервисы. Никто не говорит свой nest.js с нуля написать. Микросервисы общие нельзя делать потому что вход выход несколько отличается, разные продукты и правообладатели, а вот использовать общую библиотеку в 2 сервисах совсем другое дело.
А есть вариант посадить аналитика, разбить проект на сущности и функциональности, посмотреть что уже реализовано и MVP составить из того что есть среди реализованных функциональностей (если требуется быстрый запуск, что происходит в 90% случаев, всякие гос контракты и т.п.). А потом параллельно допилить в разных командах части системы.
Если речь идёт исключительно о фиче внутри продукта - смотрите к чему фича относится функционально и в той команде её делают. Не понимаю какие проблемы у Вас с постановкой, но они явно есть, потому что не пообщеал, а вот задача в спринте и цель спринта, взял и сделал.
Проекты в любом случае, если это не какие то велосипеды основаны на библиотеках, которые НАДО обновлять. И судя по всему Вы этого не делаете?
Ну так если 5 лет заниматься одним продуктом, о каком тонусе идёт речь? А вот если это разные продукты, но при этом ты делаешь что-то именно в своей компетенции, с тонусом проблем нет. К тому же можно перейти в другую команду с другими компетенциями и поднять тонус там.
Смотря речь о ком, джуны мидлы 99% класть хотели на все нюансы продуктов, дайте четкую задачу, мы сделаем. А у сеньеров и лидов в развлечениях разные продукты, шлифование библиотек, брейнштормы как правильно сделать что-то чтобы можно было зашить в библиотеку и переиспользовать на других проектах
В процессе, примерно год уйдёт на перестроение, как внедрим обязательно напишу новую статью со ссылкой на эту
То что читал про сильную матрицу немного про другое, может скинете что где прочитать, чтобы сказать да, это просто аналогия сильной матрицы?
Что лучше? - "ты отвечаешь за интеграции" или "вот тебе 8 продуктов, одни написаны 5 лет назад, другие вот в процессе написания, изучай потому что написаны с разными подходами и вот тебе пачка задач во всех продуктах по чуть чуть в разных частях и ты не должен ничего сломать." Учитывая что у тебя большая часть команды мидлы, периодически приходят джуна, а сеньеров штук 5 и они заняты другими продуктами
Каша с задачами решается четкими целями в спринте. У каждой функциональной команды свой руководитель. А ПМ-у да, нужно будет с них спрашивать. Плюс команды работают уже по проработанной аналитиками бизнес логике. На низовом уровне ничего не изменится.
Не соглашусь. Это так, когда тим лид отвечает за продукт. А когда тим лид отвечает за функциональную область, он прорабатывает эту область со всей командой и вся команда примерно всё знает, потому что ей не нужно распыляться на знание всего продукта
Задача ПМ-а и аналитика разобраться в продукте с точки зрения бизнеса и все знания задокументировать. То есть бизнес процессы и сущности будут задокументированы и понятны всем кому нужно, а разрабам это и вовсе не нужно, особенно джунам и мидлам, которые в основном чисто механическую работу делают.
Ну и тут писал
Полностью он конечно же не уйдет. Тут вопрос выгоды, что проще - найти пм-а или сеньера?
Можно пример? Потому что RnD может быть продуктовый, что обычно не нужно, это задача менеджмента и аналитиков понять боль бизнеса. А может быть RnD функциональный, который целиком уходит в какую то из команд, прорабатывается и возможно внедряется и на других продуктах.
Документация, спринты, цели спринтов помогают четко понимать что мы делаем и куда идём
Можно пример? Потому что Я вижу размышления только про продуктовый подход, который висит из всех щелей откуда хоть что-то можно услышать про менеджмент. Яндекс, майкрософт, гугл, всякие банки, операторы связи и т.д. (см. любую конференцию)
Тут скорее про количество продуктов или их величину
Потому что подход на стадии внедрения. Ну сразу могу сказать, на 8 продуктов вместо 8 команд продуктовых из разномастных спецов, нужно 6 функциональных команд с другим подходом. Плюс планируется ещё несколько продуктов, на которые не надо нанимать новую команду, а функционал поделить и реализовать имеющимися командами.
Просто тупо - это ключевое
Я вижу фонтаны излияний, которые больше похожи на нытье человека, который не хочет менять привычный порядок вещей, который нагрел себе место и не хочет двигаться. Отсюда и заявления типа Устаревание кода - это просто данность, сразу четко виден подход х%як х%як, в продакшн и забыли.
Как связано глобальное состояние и транзакции?
Глобальное состояние это то что хранит сервер в себе, вне зависимости от текущего запроса, транзакция происходит по запросу и в рамках него. Чем транзакционность на уровне бизнес процесса отличается от транзакционности внутри домена? И как это вообще может быть связано с глобальным состоянием?
Совершенно верно, потому что бизнес логика лежит на уровне домена. А вот транзакционность и откат транзакции относится к бизнес процессу. Внимательнее на схему посмотрите, она вроде простая, хотя видимо не очень.
Примеры?!
Чем именно? Конкретный пример, что тут не так. Или Вы пустозвон уважаемый?
При чем тут большие графы и как они связаны с конкретно этой архитектурой? Я извиняюсь Вы вообще программист? Я уверен, Вы вообще не понимаете то, о чем пишете.
Теперь Я точно уверен что Вы не понимаете о чем пишете. Просто сотрясаете воздух терминами, в которых не разбираетесь.
Тем, кто будет читать данный комментарий: просто прочитайте про анемичную модель и сравните с тем, что пишет данный индивид выше.
А, Вы предлагаете поступить как Вы — "не понимаю, ну и ладно, буду кидаться сложными терминами в комментариях". Нет, спасибо.
Ну оно и видно, что Вы сложнее CRUD-а в своей жизни никогда ничего не писали.
В заключение:
Я попросил конкретных примеров и советов, Вы начали оскорблять, уклоняться от ответа, и уходить ещё глубже в теорию, которую сами не понимаете.
С Вами всё понятно, тут нечего обсуждать, лучше идите пару приложений напишите, опыта наберитесь.
Объяснили понятно, спасибо.
По моему DDD не совсем про это. Домены обособляются не потому что "так надо", а потому что каждый домен — это большой пласт нюансов, который по хорошему должен разрабатываться отдельной командой, но при этом чтобы был понятен другим и его можно было легко протестировать и использовать.
А что мешает задублировать внутрянку бизнес процесса? Это даже не будет нарушением DRY, потому что бизнес процесс может измениться (сейчас он похож на другой, а потом станет не похож) или отличаться маленьким нюансом, из за которого придется дочерний бизнес процесс переписывать и учитывать этот нюанс, а это уже приводит к неоднозначности ответа от бизнес процесса, что нарушает те маленькие правила, которые Я для себя вывел.
К тому же если так сгущать краски, можно любую архитектуру "запороть", важно соблюдать баланс. Я например не могу придумать сценарий, где "придется" городить супер бизнес процесс.
По поводу предполагаемого метода createPartner, это сработает, пока нет каких то особенностей. Но как только какая то часть внутри усложнится метод createPartner превратится в 100-строчный код с кучей if-ов, уже видел неоднократно.
Речь идёт не про то чтобы код был красивым после написания приложения, а про то чтобы его можно было поддерживать и расширять, потому что бизнес меняется, условия меняются и надо быстро и удобно развивать приложение. Это кстати огромная беда, что разработчики думают только про момент запуска приложения и совсем не думают о последующих этапах жизненного цикла.
Ещё одной проблемой является тестирование, подмена всех зависимостей в композитных методах — это будет адище.
По поводу сложности приложения — про DDD начинают задумываться после прохождения определенной точки сложности проекта, когда добавление маленькой фичи оборачивается огромным пластом работ. Вы предлагаете метод от сложного к простому, но обычно проект развивается от простого к сложному и появляется необходимость во всём вот этом. Когда есть маленький сервис, конечно DDD, даже в минимальной своей реализации избыточен.
Согласен с критикой.
По поводу инъекций, тут можно нагородить как в Nest-е, но для меня это кажется избыточным, а так да, можно DI полноценный реализовать и не руками внутрь пробрасывать, а через DI.
Да, каждый вышестоящий слой связан с предыдущим, а адаптеры связаны как с предыдущим так и с вышестоящим (на картинке в виде выступов на самом блоке). Но если не брать теоретические модели, то в практике полностью несвязанные сущности сделать либо невозможно, либо овчинка выделки не будет стоить, по сложности. Поэтому есть абстракции в виде адаптеров, чтобы не быть связанным с конкретной БД или конкретным API.
С этой стороны не смотрел, есть такое. Тут скорее описание как сделать средний слой)
Я и не говорю, что делаю каноничную… Я сделал ту, которая мне сильно упростила работу, при этом соответствует моим критериям "красоты". Делал на основе гексагональной, которую изначально пытался взять за основу, но наткнулся на неудобства.