Всем привет! Снова архитекторы скучают и хочется руками пощупать что-то новое и создать что-то с нуля. Как развиваться на работе, если ты уже свой стек технологий знаешь досконально или достаточно для выполнения падающих на тебя задач? Конечно же, свой проект. Кто-то пишет скрипты на новом языке, кто-то пробует новую библиотечку, я решил попытаться в свободное от работы время прорабатывать огромную задачу по созданию банка и планирую не просто рисовать квадратики и стрелочки, а всё документировать, и руками воплощать. Текущая статья будет полезна разработчикам, которые хотят стать архитекторами или просто хотят посмотреть примеры проработки архитектуры и использования архитектурной нотации Archimate. Я не так давно создал с нуля пользователя на github и приступил к работе.
Хотел поделиться своим прогрессом в one-man-bank проекте и сказать, что я реально кайфую от архитектурного инструмента под названием Archi. В проекте уже есть небольшая проработка бизнес целей, требований, бизнес-возможностей, value stream и сейчас пойдет речь об артефакте «Архитектура Решения» или то, что в книгах называют Solution Architect Document (не ругайте строго, я его не доделал еще).
Планирую написать статейку с обзором пяти инструментов, которые я пробовал и использовал в работе за последние 2 года для того, чтобы составлять архитектурные диаграммы в нотации Archimate.
А пока небольшая затравка по проекту и кратко о Архимейте.
Что такое Архимейт
Архимейт – это архитектурная нотация с довольно широкой метамоделью, с помощью этой метамодели можно описывать разные слои предприятия или view point'ы.
Как по мне, самым актуальным и часто используемым является, не побоюсь этого слова, ядро этой метамодели. А именно бизнес-слой (желтый), слой приложений (синий), технологический/инфраструктурный слой (зеленый).
Используя эти 3 уровня архитекторы решений могут понять, через какие компоненты будут реализовываться бизнес-процессы, а затем и какая инфраструктура нужна для работы этих приложений.
В Архимейте есть и другие слои Strategy, Motivation, Implementation & Migration, но это тема для отдельного разговора.
К слову, был период у меня в жизни, когда я был уже опытным java-разработчиком (опыт 7+ лет) и даже Team Lead'ом джавистов (опыт 9+ лет) и меня не брали архитектором потому, что я не имел практического опыта работы с архитектурными нотациями Archimate и C4, хотя я уже имел приличный опыт за спиной (работали в командах без архитекторов и их надзора, в глаза не видели архитектурных артефактов и рисовали сами всё в draw.io).
Итак мы подходим к тому минимальному примеру: как это выглядит на самом деле. Я как раз только ночью запушил диаграммы уровня приложений (синие) и уровня инфраструктуры (зеленые) и хотел бы поделиться таким минимальным примером, который буду развивать дальше, поэтому есть смысл и сейчас заглянуть в репозиторий и попозже. Ссылочка на страничку с артефактом решения.
Диаграмма взаимодействия компонентов (Application Layer)
На Application layer всё довольно просто и понятно, любой разработчик поймёт такую диаграмму, ведь она могла бы быть нарисована и в draw.io с белыми прямоугольниками.
На диаграмме я постарался называть компоненты так, как планирую называть репозитории на самом деле. Простые сплошные стрелки – это связь triggering (инициирует или запускает) под ней я подразумеваю синхронный вызов по HTTP.
Например, в связи 2 микросервис one-man-bank-deposits вызывает one-man-bank-accounts.
Также есть связь Flow (поток) на диаграмме в связи №5. Это поток данных, в данном случае — асинхронный.
И есть третий тип связи – это композиция. Bank Employee Web App состоит из one-man-bank-cash-office-web и one-man-bank-deposit-web.
В данном случае это может быть два репозитория с микрофронтендом встраиваемые в общее банковское приложение для сотрудников банка.
Всё довольно понятно пока, и тут мы погружаемся в уровень инфры и в целом именно архитекторы решают, какими средствами будет реализовываться задача. Какой стэк технологий, какие протоколы, нужен ли свой Kubernetes или будет облачное решение, а может это просто сервак куда мы по ssh перелили архив и ручками запускаем спринг приложение через java -jar ... (я и это делал, когда спринг конфигурили XMLем в стартапе).
Диаграмма развёртывания (Deployment diagram)
Диаграмма развёртывания (Deployment diagram) – это одна из самых важных диаграмм, которые существуют, на которой описывается, на каких узлах, в каких сетках крутится что-то (k8s, kafka и т. д.) и как эти компоненты связываются друг с другом.
Скажу честно, я воспользовался нотацией моих замечательных бывших коллег для диаграммы развертывания и сделал лишь 1 отличие в связи между svc (service/служба в k8s) и deployment.
Теперь мы, грубо говоря, приземлили уровень приложений на уровень инфры, сказали как ходить, какие протоколы и какие порты. Немного поясню диаграмму на пальцах: в Deployment'е находятся наши поды, внутри которых крутятся контейнеры с нашими приложениями (на самом деле всё посложнее, грубо говоря, Deployment управляет ReplicaSet'ом, который управляет уже подами. При создании deployment'a вы можете увидеть эти объекты через kubectl get deploy, kubectl get rs, kubectl get pods).
С Deployment разобрались, теперь service – это абстракция над kube-proxy в ваших воркерах, которая по лейблам понимает, на какие поды распределять трафик.
А зачем тут ингрессы. По умолчанию сервисы имеют тип ClusterIp и не доступны снаружи кластера, но доступны внутри. Ingress (ингресс-правило) говорит, какой URL смапить в какой service. Например сейчас мы просто хотим, чтобы мы могли и вэб приложение дернуть и swagger конкретных сервисов. Может, в будущем мы уберем их, но пока пусть будет так.
К слову, сами Ingress объекты не работают без Ingress Controller'a, тоже самое будет и с Network Policy. Но это не в рамках этого поста и я писал об этом ранее.
Итак получается: мы в рамках SAD (документы архитектуры решения) проработали то, как мы приземлим один из процессов, необходимых для реализации бизнес требования. Круто, но не обольщаемся — этот артефакт далёк от готовности.
Напоследок
Эти диаграммы — не просто картинки. Каждый элемент – это объект в шикарном инструменте под названием Archi, а значит мы можем переиспользовать эти объекты в других диаграммах и иметь порядок в нашем архитектурном репозитории. Archi бесплатный, можете скачать и попробовать.
В планах будет и создание всех yaml'ов, необходимых для нужных нам объектов Kubernetes. Девопсы это умеют, а вот разрабам было бы интересно и полезно. Да и не только это.
Если было чуточку интересно и вы дочитали до этого предложения, то буду рад любой реакции или комментарию.
Всем хорошего рабочего дня.
Мой тг-канал: https://t.me/talismanovIT
Комментарии