Дополнил статью в соответствии с комментариями по различиям между "Адаптацией" и "Посредничеством". По вопросам оркестрации и хореографии вынесем разбор подходов и детали реализации в следующую статью. И спасибо большое за вашу вовлеченность в обсуждение!
Спасибо большое за такой развернутый комментарий и фидбек. Ниже постараюсь ответить на часть вопросов. Более того, на основе вопросов частично дополню текущую статью, остальное - учту в следующем материале.
Итак, к ответам.
Про критический путь.
В первом случае нет никакого паттерна — просто прямое общение, без оптимизаций, на основе доменной логики, за исключением разбития по слоям, и настройки взаимодействия модулей из разных слоев между собой. Этот пример нужен для начала размышлений об оптимизациях.
Про «Медиатор» — хороший поинт. Вы абсолютно правы. Но я немного уточню. Я парадигмально размышляю так: - Действительно модуль верхнего уровня является «Медиатором» для общения модулей нижнего слоя между собой, устраняя связанность этих модулей между собой. - В тоже время, нужно учитывать, что модули нижнего модуля в момент оптимизации, скорее всего знают, как общаться между собой. И за счет инверсии зависимостей, чаще всего, выделяются объекты/методы взаимодействия, которые модуль верхнего уровня «адаптирует». То есть запросы/методы от каждого из модулей «адаптируются» в АПИ соседнего модуля, с которым нужно взаимодействовать. - Поэтому я расширю описание этого пункта и добавлю проведения аналогии с «Медиатором» для прозрачности.
Последний вариант действительно несет много накладных расходов на разработку: усложняется DI и появляются сущности API модулей. И тут мое мнение, что при маленьких и средних проектах его внедрение сложно оправдать. Все изменяется когда проект подходит к размерам большого. Часто проекты приходят к этому «эмпирически», но я бы тут отметил правило, что это происходит тогда, когда компиляция при разработке продуктовых фичей начинает влиять на Time to market. В таком случае, и это тот путь, к которому сейчас идем мы внутри нашего проекта, API/IMPL подход применяется к фиче-модулям, то есть к тем модулям, где происходит около 90% всей разработки и 99% продуктовой разработки. Просто потому, что поддержав для конкретного продуктового модуля API/IMPL один раз, потратив на это время, продуктовая команда сильно экономит на расходах при разработке в этом модуле, за счет компиляции и, как правило, «правильнее» подходит к проектированию API модуля. Думаю что мы можем немного расширить статью, включив в нее терминологию оркестрации и хореографии. Для дополнительной аналогии.
Мы используем Nexus для кеширования зависимостей, чтобы изолировать наш внутренний контур от интернета. Также мы решаем проблемы кибербезопасности — артефакты на Nexus проверяются отделом КБ на предмет уязвимостей. Уточните пожалуйста по этому вопросу, что конкретно хотелось бы узнать/прочесть? Постараемся учесть ваши пожелания в будущей статье.
Мы долгое время уже живем как раз в реалиях хореографического принципа. Но, как отметил выше, идем в сторону API/Impl на уровне фиче-модулей. Причем тут задача платформенной команды объяснить продуктовым командам как работать в этом подходе и внедрить или помочь внедрить подход в продуктовый модуль.
Причина: рост проекта и снятие метрик и настроения разработчиков касательно времени компиляции. Мы расскажем о конкретных решениях и истории нашего пути в следующей статье.
Градация выведена внутри нашей команды. Если быть точным — мной. И отлично относится к критике. Не могу тут, к сожалению, поделиться ссылкой. Я думаю, что в абсолютном большинстве случаев изолировать не удастся и такая зависимость прочно укрепится в вашем технологическом стеке и будет влиять на ваш найм. Решение тут почти во всех командах, где я работал, приходит к тому, чтобы просто при устаревании технологии, помечать ее deprecated (в вашем технологическом радаре) и планово (в рамках технического долга или других практик устранения Legacy кода), устранять/переходить на новые технологии.
Спасибо за комментарий!
Здесь действительно была опечатка в статье, исправил.
Дополнил статью в соответствии с комментариями по различиям между "Адаптацией" и "Посредничеством".
По вопросам оркестрации и хореографии вынесем разбор подходов и детали реализации в следующую статью.
И спасибо большое за вашу вовлеченность в обсуждение!
Спасибо большое за такой развернутый комментарий и фидбек. Ниже постараюсь ответить на часть вопросов. Более того, на основе вопросов частично дополню текущую статью, остальное - учту в следующем материале.
Итак, к ответам.
Про критический путь.
В первом случае нет никакого паттерна — просто прямое общение, без оптимизаций, на основе доменной логики, за исключением разбития по слоям, и настройки взаимодействия модулей из разных слоев между собой.
Этот пример нужен для начала размышлений об оптимизациях.
Про «Медиатор» — хороший поинт. Вы абсолютно правы. Но я немного уточню. Я парадигмально размышляю так:
- Действительно модуль верхнего уровня является «Медиатором» для общения модулей нижнего слоя между собой, устраняя связанность этих модулей между собой.
- В тоже время, нужно учитывать, что модули нижнего модуля в момент оптимизации, скорее всего знают, как общаться между собой. И за счет инверсии зависимостей, чаще всего, выделяются объекты/методы взаимодействия, которые модуль верхнего уровня «адаптирует». То есть запросы/методы от каждого из модулей «адаптируются» в АПИ соседнего модуля, с которым нужно взаимодействовать.
- Поэтому я расширю описание этого пункта и добавлю проведения аналогии с «Медиатором» для прозрачности.
Последний вариант действительно несет много накладных расходов на разработку: усложняется DI и появляются сущности API модулей.
И тут мое мнение, что при маленьких и средних проектах его внедрение сложно оправдать.
Все изменяется когда проект подходит к размерам большого. Часто проекты приходят к этому «эмпирически», но я бы тут отметил правило, что это происходит тогда, когда компиляция при разработке продуктовых фичей начинает влиять на Time to market.
В таком случае, и это тот путь, к которому сейчас идем мы внутри нашего проекта, API/IMPL подход применяется к фиче-модулям, то есть к тем модулям, где происходит около 90% всей разработки и 99% продуктовой разработки.
Просто потому, что поддержав для конкретного продуктового модуля API/IMPL один раз, потратив на это время, продуктовая команда сильно экономит на расходах при разработке в этом модуле, за счет компиляции и, как правило, «правильнее» подходит к проектированию API модуля.
Думаю что мы можем немного расширить статью, включив в нее терминологию оркестрации и хореографии. Для дополнительной аналогии.
Мы используем Nexus для кеширования зависимостей, чтобы изолировать наш внутренний контур от интернета. Также мы решаем проблемы кибербезопасности — артефакты на Nexus проверяются отделом КБ на предмет уязвимостей.
Уточните пожалуйста по этому вопросу, что конкретно хотелось бы узнать/прочесть? Постараемся учесть ваши пожелания в будущей статье.
Мы долгое время уже живем как раз в реалиях хореографического принципа. Но, как отметил выше, идем в сторону API/Impl на уровне фиче-модулей. Причем тут задача платформенной команды объяснить продуктовым командам как работать в этом подходе и внедрить или помочь внедрить подход в продуктовый модуль.
Причина: рост проекта и снятие метрик и настроения разработчиков касательно времени компиляции.
Мы расскажем о конкретных решениях и истории нашего пути в следующей статье.
Градация выведена внутри нашей команды. Если быть точным — мной. И отлично относится к критике. Не могу тут, к сожалению, поделиться ссылкой.
Я думаю, что в абсолютном большинстве случаев изолировать не удастся и такая зависимость прочно укрепится в вашем технологическом стеке и будет влиять на ваш найм.
Решение тут почти во всех командах, где я работал, приходит к тому, чтобы просто при устаревании технологии, помечать ее deprecated (в вашем технологическом радаре) и планово (в рамках технического долга или других практик устранения Legacy кода), устранять/переходить на новые технологии.