Если копнуть глубже и посмотреть очень схематично на визуализацию микросервисной архитектуры, то мы увидим, что вполне возможно выделить два уровня. Первый будет в себя включать модель предметной области и техническую макро-архитектуру. Например, именно здесь мы определяем чаще всего такие вещи, как: отвественности компонентов (сервисов), интеграция с UI, протоколы взаимодействия, форматы данных, избыточность данных (redundant data), логирование и мониторинг (и другие входящие в состав microservices chassis параметры). Это не обязательный список и он может варьироваться в зависимости от контекста конкретного решения.
Если копнуть глубже и посмотреть очень схематично на визуализацию…
Из этого канала
- #134Второй же уровень вполне можно отдать на откуп команд. Главное условие —…
Второй же уровень вполне можно отдать на откуп команд. Главное условие — инженерные/архитектурные решения, принимаемые на этом уровне не должны нарушать…
- #135Получается такая аккуратная картинка, которая достаточно неплохо встраивается…
Получается такая аккуратная картинка, которая достаточно неплохо встраивается в текущие процесссы любой организации от стартапа до very big enterprise.
- #136Старенькая статья «Why Netflix Moved to a Microservices Architecture»…
Старенькая статья «Why Netflix Moved to a Microservices Architecture»…
- #132Адаптированный цикл выглядит так. Есть цель, а есть ASR, NFR(QA), принципы и…
Адаптированный цикл выглядит так. Есть цель, а есть ASR, NFR(QA), принципы и ограничения в поддержку этой бизнес-ценности. Они ограничивают целевое решение.
- #131Хочу рассказать об уровнях принятия решений в микросервисной архитектуре. То,…
Хочу рассказать об уровнях принятия решений в микросервисной архитектуре. То, что я использую в своей практике — это двойная петля обучения Криса Аргириса,…