Могу сказать по прошлому году, когда моя статья победила – читатели приходят и очень прилично ) А вот по шортлисту, что в этом, что в прошлом году – действительно практически нет
не уверен что до конца верно понял ваш посыл 😅. Что касается гранулярности как метрики архитектуры — да, есть такая метрика, но она лишь как-то характеризует систему: к примеру насколько мелко нарезаны микросервисы. Т.е. ни мелкая, ни крупная гранулярность не являются ошибкой или удачным решением в общем случае, это лишь характеристика (ни хорошая, ни плохая) выбранной стратегии. Подробнее об этом писал в своей статье: https://habr.com/ru/companies/oleg-bunin/articles/699750/
да-да, я ж ровно об этом и говорю — весь вопрос в том, как мы проводим границы. По сравнению с точками, в случае ИТ-проектов дополнительные сложность и ограничения в том, что место проведения границ обычно ещё и имеет свою физическую (например, сетевую) состовляющую или даже административную (разделение ответственности команд).
Важно правильно очертить границы, чтобы к примеру нужный сервис попал в ответственность к правильной команде
Фронт работает только с одним микросервисом — со специально выделенным для него BFF (backend for frontend), который уже в свою очередь работает с различными компонентами/микросервисами, но уже внутри периметра. В редких случаях особо сложных фронтендов — делаем несколько BFF, повторяющих структуру компонентизации микрофронтов на UI.
Так же, иногда разделяют BFF для декстопа и для мобильного приложения, но я тут обычно советую так делать только в случае сильно разного API для браузера и мобилки (ещё надо смотреть почему оно разное)
примеры и разборы больших архитектур на предмет измерения метрик и проверки соблюдения принципа планирую оформить отдельной статьёй :) Наброски инструмента проверки архитектур, описанных по C4-модели, пока висят в непринятом PR'е: https://github.com/Byndyusoft/aact/pull/14 Как только стабилизируем инструмент — обязательно напишу и разберём с помощью него какую-нибудь большую реальную архитектуру :)
давайте по порядку ) у swagger'а изначально и нет такой цели — он про контракт, а не про его использование. Использование и взаимосвязи — это как раз к архитектуре (про это пишу в приведенной выше ссылкой статье). В yaml'ах бизнес-составляющую тоже, естественно, размещать не стоит, хотя там уже могут быть как раз связи с другими сервисами (разрешённые исходящие REST-вызовы, подписки на очереди и т.д.). В качестве всегда актуальной документации бизнес-логики могу посоветовать BPMN-схемы и движки их исполняющие. Мы используем, например, Camunda. Но в целом, вопрос описания назначения сервисов и т.д. автодокументацией или тестами не закрыт — согласен, рассуждаю об этом в приведенном выше докладе (часть про автогенерацию архитектуры), или в отдельном более коротком: https://www.youtube.com/watch?v=fb2UjqjHGUE Если интересно — можно ознакомиться.
А вот про любую ошибку в описании — если выполнить мои рекомендации по архитектуре и инфре as Code и связыванию их тестами, то ошибка отловится автоматически (несоответствие yaml'а архитектурной схеме к примеру) и тест сразу покажет в каком файле и какая допущена неточность. Тот же тест в другом случае скажет, что наоборот — в yaml'е мы изменения внесли, а вот в схемку — забыли. Ну и помимо тестов естественно должен быть ещё мониторинг как на уровне успешности CI/CD процессов, так и реалтайм эксплуатации
Как раз в прошлой статье описываю, что не только – как автоматическими тестами контролировать актуальность схем взаимосвязей и соблюдение принципов проектирования. Статья победила в Хабровском Технотексте )
Почему такое движение это движение именно по второй координате времени, а не к примеру по 4-й, 5-й или N-й координате пространства? Интуитивно, это больше пространственное движение, т.к. оно не неостановимо и не направленно в одну сторону как время (можно остановиться или двигаться в любую из сторон "вбок")
скажите это многим открытиям в физике, которые были изначально предсказаны математикой на бумаге :)
А про двумерное время – уже после написания статьи наткнулся на обзоры научных работ по многомерному времени. Например, при расчетах в двумерном времени сходится с экспериментальными измерениями космологическая постоянная (в расчетах с привычным временем – расходится минимум на 50 порядков): https://www.scirp.org/journal/paperinformation?paperid=102749
A Solution to the Cosmological Constant Problem in Two Time Dimensions
Спасибо за подробный разбор :) Отчасти согласен, но далеко не со всем. К примеру:
Стоп... актуализации? Т.е. та самая проблема, которая должна была решиться, возникает в новом качестве? Теперь она блокирует развертывание не только, если у вас что-то в коде и конфиге не так. Теперь придется найти ту самую диаграмму которая не сходится с конфигом и ее тоже поправить. Как ее найти? Кто поправить должен? Решение не предложено.
Как раз на самом раннем этапе тест и покажет максимально точно что и где нужно поправить. Если нужны изменения в архитектурной схеме — это делает разработчик и отправляет на ревью архитектору (ответственному за архитектуру решения тимлиду/техлиду).
В целом, как в треде уже отметили — это лишь первый шаг, на котором я не остановился (к примеру есть уже следующий шаг в плане автогенерации архитектурных схем) и не планирую останавливаться в дальнейшем =)
постараюсь выделить несколько причин: - потребителями одних и тех же данных могут быть несколько разных бизнес-логик; - нагрузка и ресурсоёмкость операций извлечения и обработки данных обычно разные. В случае совмещения, мы не сможем смасштабировать, к примеру, только операции обработки данных; - оба пункта выше являются конкретными примерами возможных проблем нарушения базового принципа единственности ответственности
тут вопрос во взаимодействии с пользователем, т.е. в UI/UX. Если мы понимаем, что за увлоный таймаут в 1 секунду мы не сможем пользователю сказать, что всё ок, транзакция выполнена или не ок, завершилась с ошибкой — то пользователю явно прозрачно об этом сообщаем. К примеру, секунду крутим лоадер, если за секунду не успели — говорим, что ещё обрабатывается, результат пришлём на почту, вкладку можно закрыть (или, "пожалуйста не закрывайте вкладку, обновим статус операции через 10 секунд"). Короче не кидаем пользователя в неопределенности с бесконечным лоадером. Но это уже несколько отдельная от отказоустойчивости тема :)
в вашем случае умирать быстро должны подключения и по цепочке запросы их инициализирующие, далее должен сработать circuit breaker. К сожалению, любой подход или паттерн можно понять и использовать искаженным образом — в общем случае, это не означает что принцип не верен
Могу сказать по прошлому году, когда моя статья победила – читатели приходят и очень прилично ) А вот по шортлисту, что в этом, что в прошлом году – действительно практически нет
не уверен что до конца верно понял ваш посыл 😅. Что касается гранулярности как метрики архитектуры — да, есть такая метрика, но она лишь как-то характеризует систему: к примеру насколько мелко нарезаны микросервисы. Т.е. ни мелкая, ни крупная гранулярность не являются ошибкой или удачным решением в общем случае, это лишь характеристика (ни хорошая, ни плохая) выбранной стратегии. Подробнее об этом писал в своей статье: https://habr.com/ru/companies/oleg-bunin/articles/699750/
да-да, я ж ровно об этом и говорю — весь вопрос в том, как мы проводим границы. По сравнению с точками, в случае ИТ-проектов дополнительные сложность и ограничения в том, что место проведения границ обычно ещё и имеет свою физическую (например, сетевую) состовляющую или даже административную (разделение ответственности команд).
Важно правильно очертить границы, чтобы к примеру нужный сервис попал в ответственность к правильной команде
Фронт работает только с одним микросервисом — со специально выделенным для него BFF (backend for frontend), который уже в свою очередь работает с различными компонентами/микросервисами, но уже внутри периметра. В редких случаях особо сложных фронтендов — делаем несколько BFF, повторяющих структуру компонентизации микрофронтов на UI.
Так же, иногда разделяют BFF для декстопа и для мобильного приложения, но я тут обычно советую так делать только в случае сильно разного API для браузера и мобилки (ещё надо смотреть почему оно разное)
чуть-чуть касался этой темы и темы ограниченных контекстов в своей статье про гранулярность: https://habr.com/ru/companies/oleg-bunin/articles/699750/
тут нет какого-то уникального подхода — всё стандартно как и всегда при DDD-анализе и проектировании микросервисов.
К примеру, у микрософта в гайдлайне по микросервисом это более-менее прилично описано:
https://learn.microsoft.com/en-us/azure/architecture/microservices/model/domain-analysis
нет ) к сожалению, не читал. Видимо нужно ознакомиться :)
примеры и разборы больших архитектур на предмет измерения метрик и проверки соблюдения принципа планирую оформить отдельной статьёй :)
Наброски инструмента проверки архитектур, описанных по C4-модели, пока висят в непринятом PR'е: https://github.com/Byndyusoft/aact/pull/14
Как только стабилизируем инструмент — обязательно напишу и разберём с помощью него какую-нибудь большую реальную архитектуру :)
давайте по порядку ) у swagger'а изначально и нет такой цели — он про контракт, а не про его использование. Использование и взаимосвязи — это как раз к архитектуре (про это пишу в приведенной выше ссылкой статье).
В yaml'ах бизнес-составляющую тоже, естественно, размещать не стоит, хотя там уже могут быть как раз связи с другими сервисами (разрешённые исходящие REST-вызовы, подписки на очереди и т.д.).
В качестве всегда актуальной документации бизнес-логики могу посоветовать BPMN-схемы и движки их исполняющие. Мы используем, например, Camunda.
Но в целом, вопрос описания назначения сервисов и т.д. автодокументацией или тестами не закрыт — согласен, рассуждаю об этом в приведенном выше докладе (часть про автогенерацию архитектуры), или в отдельном более коротком: https://www.youtube.com/watch?v=fb2UjqjHGUE
Если интересно — можно ознакомиться.
А вот про любую ошибку в описании — если выполнить мои рекомендации по архитектуре и инфре as Code и связыванию их тестами, то ошибка отловится автоматически (несоответствие yaml'а архитектурной схеме к примеру) и тест сразу покажет в каком файле и какая допущена неточность. Тот же тест в другом случае скажет, что наоборот — в yaml'е мы изменения внесли, а вот в схемку — забыли.
Ну и помимо тестов естественно должен быть ещё мониторинг как на уровне успешности CI/CD процессов, так и реалтайм эксплуатации
Как раз в прошлой статье описываю, что не только – как автоматическими тестами контролировать актуальность схем взаимосвязей и соблюдение принципов проектирования. Статья победила в Хабровском Технотексте )
https://habr.com/ru/articles/800205/
да, хороший вариант. Но я бы его назвал совмещением первых двух вариантов, но не третьим (иным, отличающимся) 😉
Почему такое движение это движение именно по второй координате времени, а не к примеру по 4-й, 5-й или N-й координате пространства? Интуитивно, это больше пространственное движение, т.к. оно не неостановимо и не направленно в одну сторону как время (можно остановиться или двигаться в любую из сторон "вбок")
скажите это многим открытиям в физике, которые были изначально предсказаны математикой на бумаге :)
А про двумерное время – уже после написания статьи наткнулся на обзоры научных работ по многомерному времени. Например, при расчетах в двумерном времени сходится с экспериментальными измерениями космологическая постоянная (в расчетах с привычным временем – расходится минимум на 50 порядков): https://www.scirp.org/journal/paperinformation?paperid=102749
Сказать, что я офигел, увидев свою статью в победителях (бэкенд) – ничего не сказать )))
Организаторам и жюри огромный респект!
Погодите, так ведь на странице конкурса так и написано:
возможно это я ?. Тоже выбирал категорию, исходя из сложности материала
Спасибо за подробный разбор :) Отчасти согласен, но далеко не со всем. К примеру:
Как раз на самом раннем этапе тест и покажет максимально точно что и где нужно поправить. Если нужны изменения в архитектурной схеме — это делает разработчик и отправляет на ревью архитектору (ответственному за архитектуру решения тимлиду/техлиду).
В целом, как в треде уже отметили — это лишь первый шаг, на котором я не остановился (к примеру есть уже следующий шаг в плане автогенерации архитектурных схем) и не планирую останавливаться в дальнейшем =)
Лично мне нравится ресурс: https://microservices.io/
Конкретно про ACL-паттерн, есть здесь: https://learn.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer, но в несколько другом варианте реализации.
Также у меня есть несколько докладов про архитектуру и паттерны. Тут в том числе про ACL паттерн:
А тут в целом про более общие принципы проектирования:
постараюсь выделить несколько причин:
- потребителями одних и тех же данных могут быть несколько разных бизнес-логик;
- нагрузка и ресурсоёмкость операций извлечения и обработки данных обычно разные. В случае совмещения, мы не сможем смасштабировать, к примеру, только операции обработки данных;
- оба пункта выше являются конкретными примерами возможных проблем нарушения базового принципа единственности ответственности
тут вопрос во взаимодействии с пользователем, т.е. в UI/UX. Если мы понимаем, что за увлоный таймаут в 1 секунду мы не сможем пользователю сказать, что всё ок, транзакция выполнена или не ок, завершилась с ошибкой — то пользователю явно прозрачно об этом сообщаем. К примеру, секунду крутим лоадер, если за секунду не успели — говорим, что ещё обрабатывается, результат пришлём на почту, вкладку можно закрыть (или, "пожалуйста не закрывайте вкладку, обновим статус операции через 10 секунд"). Короче не кидаем пользователя в неопределенности с бесконечным лоадером. Но это уже несколько отдельная от отказоустойчивости тема :)
в вашем случае умирать быстро должны подключения и по цепочке запросы их инициализирующие, далее должен сработать circuit breaker. К сожалению, любой подход или паттерн можно понять и использовать искаженным образом — в общем случае, это не означает что принцип не верен