В сценарии интеграций всегда есть минимум два участника. А вообще больше:


🔹Наша система (Backend) - которая отвечает за работу сценария Use Case, реализует его логику. Основная часть интеграций в проектах обычно реализуется на бэкенде.

В нашем проекте Backend GetDelivery будет:
- реализовывать логику приема и проверки данных, которые ввел пользователь, чтобы получить выгодную стоимость доставки,
- отвечать за логику вызова внешних систем - СДЭК, Деловые Линии и Возовоз,
- и обработку результатов, получаемых от них.

Также важно понимать, что и к нам могут интегрироваться, к нашему Backend. В GetDelivery это будут делать как минимум наши веб- и мобильные приложения. Для этого мы разрабатываем на сервере программные интерфейсы - API (например REST API, SOAP API, GraphQL или другие).


🔹Внешняя система - с которой мы интегрируемся, к которой делаем запросы. Важно понимать, что внешние системы в процессе интеграции могут быть как внутри одного проекта, так и за пределами - разработаны другими разработчиками, в других компаниях.

В проекте GetDelivery это системы доставки СДЭК, Деловые Линии и Возовоз.

А можно сделать распределенную архитектуру проекта и сказать, что наш сервис управления данными о пользователях будет взаимодействовать с нашим же интеграционным сервисом для расчета стоимости доставки.
Это взаимодействие = внутренняя Интеграция.

Т.к. например, сервис пользователей - основной в интеграционном Use Case для получения истории запросов пользователя, а сервис расчета стоимости может быть внешней системой по отношению к нему. Зависит от контекста.


🔹Наша система (Frontend) - мобильные приложения, веб-приложения и другие клиенты, которые могут обращаться по интеграционному API к нашему серверу за данными или для их обработки.


🔹Пользователи, которые запускают интеграционные процессы в системе.

🔺Use Case: ОБЫЧНЫЕ vs ИНТЕГРАЦИИ 🔺

Расскажу про отличия по пунктам шаблона Use Case.

-----------------------
ℹ️ Предусловие:
Отличий нет. Просто описываем что инициирует запуск сценария.


ℹ️ Роли пользователей:
Здесь могут отсутствовать пользователи, т.к. сценарий может запускаться автоматически, например, по расписанию. Но и в обычных сценариях это тоже допустимо.


ℹ️ Приложения и сервисы:
Здесь перечисляются наши приложения, системы и подсистемы, а также внешние системы, с которыми выполняется интеграция. Для внешних систем рекомендуется дать ссылку на их API-документацию.


ℹ️ Входные данные:
Здесь может быть ситуация, когда входные данные надо получать из внешней системы и сценарий начинается с обращения к ней. В это случае лучше текстом прописать какие данные и откуда получить.


ℹ️ Результат:
Отличий нет, кроме того, что итоговые данные могут быть получены из внешней системы.


ℹ️ Основной сценарий:

1. В шагах сценария указываются конкретные системы и API методы, которые отвечают за его выполнение.
При работе с интеграциями важно четко понимать, какие данные и функции доступны через API. От этого зависит, какие функции мы можем реализовать внутри Use Case.
2. Важно различать синхронное и асинхронное выполнение задач.

3. Аналитик должен понимать, как последовательно происходит исполнение задачи подсистемами (сервисами / микросервисами) проекта и внешними системами.
Описание “выполняется получение самой выгодной цены внешними сервисами” не подойдёт - слишком открытая формулировка, за которой нет конкретного решения.

4. Внешние системы могут иметь свои ограничения. Например, если их API предоставляет меньше данных, чем нам нужно, это может стать проблемой. Наоборот, если внешняя система предоставляет слишком много информации, нам придется отбирать только необходимую.
Для этого системные аналитики описывают маппинги данных к Use Case.

ℹ️ Обработка ошибок и альтернативные сценарии:

1A. Нужно учитывать что в любой момент любая внешняя система может оказаться недоступна.

1B. Обрабатывать потерю технической авторизации с внешней системой, которая не видна пользователю и восстанавливается автоматически стандартным методом ре-авторизации.

2A. Обрабатывать задержки в ответах на запросы и ошибки по тайм-ауту.

...
-----------------------

Умение видеть и выделять интеграционные Use Cases помогает заранее поставить себе в планы на аналитику четкий объем задач, избежать проблем с оценкой времени и проблем реализации разработчиками (куча вопросов после передачи требований).

Интеграции — это не просто "еще одна задача". Это серьезная работа по анализу взаимосвязей БД + Функций + UI/UX + API нашей и внешних систем, который требует нашего опыта, внимания и профессионализма 🙌 Поэтому важно уметь определять и разрабатывать требования к интеграционным Use Case.

🗼 Поговорим про архитектуру 🗽

Архитектура информационных систем — это как чертежи для строительства дома. Она описывает, как разные части программы связаны между собой и как они работают вместе.

Архитектор зданий планирует размеры комнат и их расположение, количество этажей в доме, и соответствующий размер фундамента под него. Архитектор в IT определяет, где хранятся данные, где и как они обрабатываются, как различные части системы будут взаимодействовать друг с другом.


Различают основные подходы к проектированию архитектуры:

🔹 Монолитная архитектура: всё в одном месте - один большой модуль, нагрузка в одном месте, где вся системы.

🔹 Сервисно-ориентированная архитектура (SOA): система разделена на сервисы, каждый из которых выполняет определенную функцию и общается с другими через API.

🔹 Микросервисная архитектура: Подобна SOA, но сервисы меньше и более специализированы, часто работают независимо. Как правило у каждого микросервиса есть своя независимая БД.

🔹 Событийно-ориентированная архитектура (EDA): Фокусируется на обработке событий и асинхронной связи между компонентами.

🔹 Layered (Слоистая) архитектура: Разделяет систему на слои с определенными функциями, например, слой представления UI, слой бизнес-логики, слой данных. Хотя и монолитная архитектура может быть организована в слои, вся система обычно развертывается (релизится) как единое целое, в отличие от слоистой архитектуры, где отдельные слои могут быть более независимыми.


Я хочу познакомить вас с монолитами, SOA и MSA.

Начнем с 🗽Монолитной архитектуры!

Монолитную архитектуру систем можно сравнить с одним большим зданием, где все комнаты (функции) находятся под одной крышей. Всё в одном пространстве без разделения на отдельные комнаты.

В такой архитектуре вся программа — это один большой блок, где все части тесно связаны и работают вместе. И если течет крыша и надо сделать ремонт, то будут задеты все помещения.

Монолитный подход к архитектуре был очень популярен на ранних этапах развития программирования, потому что он прост в создании и управлении. Он упрощает проект на старте разработки. Монолитные системы дешевые в разработке и запуске. До сих пор очень часто стартапы начинаются именно с монолитной архитектуры.


👆Важно помнить, если нужно что-то изменить в монолите, приходится работать со всей системой целиком. После доработки маленькой функции придётся обновлять всё приложение. Это приводит к “регламентным окнам” во время обновления, т.к. всё приложение перезапускается и становится временно недоступно пользователям.



➕ Плюсы:

+ Удобно для небольших приложений.

+ Дешево в реализации, не нужно привлекать высококвалифицированную и опытную команду. Остается идеальным решением для стартапов.

+ Просто для поддержки - всё в одном месте.


➖ Минусы:

- Если обновляем, то сразу всё - наличие регламентных окон при обновлении системы.

- При увеличении числа пользователей, масштабирование возможно только путём копирования монолита. Монолит требует много вычислительных ресурсов. Два монолита - ещё больше. Вместо того, чтобы наращивать ресурсы на отдельные части (отдельные популярные функциии), мы делаем копии монолита на серверах, чтобы иметь возможность обработать больше одновременных запросов пользователей.

- Все части сильно связаны друг с другом. При обновлении одной функции легко можно сломать несколько связанных. Систему тяжело развивать.

- Уязвимость - злоумышленник при взломе получит доступ сразу ко всей системе.



Успешные ИТ-проекты уходят от монолитной архитектуры, хотя могли именно с неё начать свой путь.

🗽 Монолитная архитектура

Если мы делаем GetDelivery в архитектуре монолита, то у нас будет такая картина:

🔺 Одна общая БД (хотя можно и несколько).

🔺 Вся логика, касающаяся регистрации и авторизации пользователей, расчета стоимости, платежей за заказы доставки или другие услуги будет в одном месте - на одном сервере. Если дорабатываем функцию создания заказа на доставку, то придется обновлять всё приложение.

🔺 Веб-приложение может быть сделано отдельно от бэкенда, а может быть неразрывно связано с ним.

🔺 У монолита может быть свой API для мобильных приложений.


Представим GetDelivery как монолит - бюджетный вариант реализации 😄

Буквально вчера я встретила знакомую в спортзале и на моё “Как дела?” она сказала:

“Пойдёт. Возможно я перееду из Калифорнии. Пока не знаю куда. Но я точно знаю, что будут изменения. Я чувствую, что по-старому мне уже не нравится и знаю, что хочу и сделаю свою жизнь другой. Но пока не знаю как это будет. Чувствую, что это переходный период.”

И так мне оказалась знакома эта история. Моя история.

“Мне не нравится сидеть на месте. Я устала от однообразия. Хочется что-то новое, лучшее. Я пока не знаю как и что, но всё будет по-другому. Рутина и однообразие - не моё, мне скучно!”

В последний раз я сказала себе это летом 2021 года, будучи в Сочи, когда случилось несколько стрессовых ситуаций, которые были даны мне с целью подсветить: ты можешь больше, не сиди на месте - это не про тебя! И тогда я вошла в такой же переходный период. Я понимала, что по-старому уже не работает, а что будет новое - не ясно.

Было страшно, было непонятно. И вот сейчас всё по-другому. Капитально. Новые проекты и работа, где я сама у себя в найме, проекты, несколько команд, половина жизни на английском, который когда-то был для меня невозможным, новые люди, город, страна, другая сторона планеты. Изменения сейчас идут постоянно!

Сбылось много всего, что я просто когда-то вписывала в мечты на 40+ или представляла себе как нереалистичное, но желанное. И всё получилось как есть сейчас. Череда событий всё сделала, а я работала над тем, чтобы из любых ситуаций забирать уроки и пользу. И просто много работала.

В жизни бывает, что ты хочешь что-то менять. Иногда для ускорения нужна помощь других людей, или ситуации. У всех по-разному. Но результат один. Если хочется лучше, то это возможно.

Я искренне благодарна ученикам GetAnalyst за обратную связь. После CustDev я всегда вижу их успешные истории, происходящие в процессе обучения. А это значит, что одно из моих желаний за последние годы исполнилось:

Помогать людям открывать новые возможности, чтобы они могли исполнять свои желания.

Продолжаем работать. Всё получится! ❤️

🗽 Сервисная архитектура, или SOA (Service-Oriented Architecture), это подход к разработке программного обеспечения, при котором приложение состоит из нескольких сервисов, взаимодействующих друг с другом.

Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенные функции.

Сервисная архитектура (SOA) включает в себя несколько сервисов, которые общаются между собой, обычно используя сетевые протоколы, например HTTP. Каждый сервис в такой архитектуре представляет собой отдельный модуль, выполняющий определенную функцию, и предоставляет API, через который другие сервисы могут запрашивать данные или вызывать его функции. Это как язык, на котором сервисы "разговаривают" друг с другом.

Обновление (или релиз) в сервисной архитектуре часто происходит на уровне отдельных сервисов, что позволяет минимизировать риск и упростить процесс внедрения новых функций или исправлений.

Одно из основных отличий от микросервисной архитектуры - несколько сервисов могут взаимодействовать с одной базой данных.


➕ Плюсы:

+ Можно легко добавлять новые сервисы или обновлять существующие, не трогая при этом всю систему, а внося изменения частично.

+ Изменения в одном сервисе редко влияют на другие при хорошей архитектуре.

+ Разработкой могут заниматься независимые друг от друга команды.

+ Одни и те же сервисы могут использоваться в разных частях приложения или даже в разных приложениях (вызываться в ходе выполнения алгоритма работы).

+ При масштабировании и увеличении числа пользователей, если мы знаем, что основная нагрузка на сервис поиска вариантов перевозки, а не на сервис платежей, то мы увеличиваем ресурсы только на него.


➖ Минусы:

- Сложность управления: требует тщательного планирования и координации между сервисами, нужна опытная команда.

- Проблемы производительности: сетевое взаимодействие между сервисами может замедлять отклик системы.

- Трудности в отладке: отслеживание ошибок может быть сложнее из-за распределенной природы системы.

Ну мы или не мы? 😀

Всем огромного заряда энергии в этот первый понедельник декабря! ❄️⛄️
Продолжаем работать с архитектурой и нашим сервисом GetDelivery.


🗽 Микросервисная архитектура (MSA) - это разновидность сервисной архитектуры (SOA).

Приложение также состоит из сервисов, но они меньше по размеру и разрабатываются под конкретные узкие задачи, то есть выполняет свои специфические функции. Эти сервисы могут быть разработаны, развернуты и обновлены независимо друг от друга. В SOA при этом сервисы могут быть больше и охватывать более широкий спектр функциональности.

В микросервисной архитектуре сервисы также взаимодействуют друг с другом с использованием простых способов, таких как API (Application Programming Interfaces). API обеспечивают стандартизированный способ передачи данных и запросов между различными сервисами, делая процесс их использования удобным при программировании для разработчиков.

Каждый микросервис имеет свою независимую БД.


➕ Плюсы:

+ Легче добавлять и обновлять функциональность.

+ Ошибки в одном микросервисе менее вероятно повлияют на всю систему.

+ Разные команды могут разрабатывать разные микросервисы параллельно, что ускоряет разработку.

+ Каждый микросервис может использовать ту технологию, которая наиболее подходит для его задач: один микросервис с в системе использует СУБД postgreSQL, второй SQLite; один с REST API, а второй с graphQL.


➖ Минусы:

- Большее количество компонентов требует более сложного управления и мониторинга.

- Общение между микросервисами через сеть может приводить к сетевым задержкам.

- Большее количество точек взаимодействия с системой увеличивает риск несанкционированного доступа. В то же время при хороших настройках безопасности это может оказаться плюсом, что утеряны будут данные только взломанного микросервиса, а не всей системы.

- Тестирование становится более сложным из-за распределенной природы системы.

Итак, для проекта GetDelivery один из вариантов сервисно-ориентированной архитектуры (SOA) может быть реализован так.

Что на схеме архитектуры? 🤔


1. Клиенты

Как и в монолите, список клиентов сохраняется. Единственное, я добавила в этот список панель администратора системы (Web App Admin), чтобы дальше рассказать про отдельные сервисы.


3. Внешние системы

Перечень внешних систем, с которыми необходимо реализовать интеграцию.
Хочу отметить, что на схеме важно показать виды API по которым будет проходить интеграция: REST API, GraphQL, SOAP API, ftp или другие. Пока я этого не сделала, но нужно будет добавить.

Также хочу обратить ваше внимание, что внешняя система - это черный ящик. На схеме архитектуры нашей системы не надо рисовать их БД, если мы о ней ничего не знаем. Мы пользуемся API для интеграций систем доставки с GetDelivery, чтобы не думать об их БД. Ведь именно с целью скрыть прямой доступ к БД СДЭК, Возовоз и Деловые Линии делали публичные API.



2. Backend - серверное приложение с сервисной архитектурой (SOA)

Рассказываю про компоненты и почему они выделены:

- База данных основная - в ней будут храниться все данные связанные с историей поиска, оформленными заказами и всем тем, что связано с базовой функциональностью системы GetDelivery. PostgreSQL.

- База данных пользователей - в ней будем хранить список зарегистрированных пользователей, историю входов в приложения, ключи (токены) доступа и другие данные, связанные с регистрацией и авторизацией пользователей. PostgreSQL.

- Файловое хранилище отчетов - выделено для хранение файлов PDF отчетов о сформированных заказах и других видах отчетов, которые может генерировать приложение администратора, с использованием соответствующего сервиса генерации отчетов.


Продолжение 👇

Продолжение - переход от монолита к SOA 👇


2. Backend - серверное приложение с сервисной архитектурой (SOA)

Рассказываю про компоненты и почему они выделены:

🔺 Сервис основной логики -
основные функции системы, которые не относятся к остальным сервисам системы. Это подобие монолита внутри сервисной архитектуры и именно так система может выглядеть в промежуточном состоянии при переходе от монолитной архитектуры к SOA или MSA.

🔺 Сервис интеграций с сервисами доставки -
чтобы не грузить ядро системы (сервис основной логики) нагрузкой по запросам к внешним системам, и с учетом того, что в системе-агрегаторе интеграции к внешним системам имеют похожие сценарии по обмену данными, мы выделяем однотипные интеграции в отдельный сервис.
В нем организуем хранение конфигураций для интеграций, общую логику для обработки ошибок и общие функции.

🔺 Сервис авторизации и регистрации пользователей -
так как пользователи, при условиях хорошей реализации требований к безопасности, могут постоянно просить ключи авторизации к системе (например, при требовании к устареванию ключа авторизации каждый час), то лучше выделить эту функциональность в отдельный сервис и держать отдельно от основной логики.

Так мы потенциально снизим количество запросов на основной сервис системы (ядро) в сотни раз, в зависимости от общего объема одновременно работающих пользователей и требований к функциональности авторизации.

Также регистрацию пользователей часто выделяют в отдельный сервис, т.к. за ней может скрываться большой объем данных и настроек пользователей, которые могут создаваться достаточно долго при вызове команды регистрации.


🔺 Сервис генерации отчетов -
предназначен для сбора данных и генерации PDF-файлов на их основе по запросам от приложения администратора. Выделение этого сервиса оправдано тем, что генерация файлов и запись их в файловое хранилище может занять длительное время и лучше это делать на отдельном сервере, выделять под это отдельные мощности.


Этот способ реализации сервисной архитектуры для проекта GetDelivery не единственный. Есть еще варианты деления приложения на сервисы, я показала только один из возможных, с учетом известных сейчас требований к проекту.

Если сравнить исходную схему монолита GetDelivery с полученной картинкой SOA, то можно увидеть наглядно как можно последовательно выделять сервисы от основного бэкенда в отдельные сервисы. Еще раз напомню - на картинке “Сервис основной логики” это монолит, из которого можно выделить еще больше сервисов и микросервисов, когда до конца разберемся с бизнес-процессами и функциональностью системы.

🌟 Визуализация - ключ к пониманию архитектуры систем 🌟

Сложность архитектуры программных систем растет, и чтобы разобраться в ней, системным аналитикам становится важно уметь её визуализировать. Подумайте о сложных системах, вроде Яндекс.Такси, Озон, YouTube, с их множеством компонентов внутри, предназначенных для реализации различных задач.

При рисовании схемы архитектуры, в которой 20 сервисов и 30 микросервисов на Backend часто встает вопрос: как же все это показать и уместить в одну схему?
При создании архитектурных схем используются разные подходы и нотации.

Среди нотаций можно выделить:
🌟 C4,
🌟 ArchiMate,
🌟 SysML,
🌟 4+1,
🌟 AADL.

Выбор зависит от особенностей проекта и предпочтений команды.
Узнать больше о каждой нотации и получить советы по их применению можно в моей статье: Архитектура систем для аналитиков: ТОП-5 нотаций моделирования архитектуры.

Для системного аналитика важно понимать, как проектировать интеграции:
🔹 исследовать API,
🔹 разрабатывать сценарии работы системы, встраивая в них вызовы соответствующих API методов,
🔹 описывать архитектуру,
🔹 разрабатывать маппинги данных,
🔹 проверять как работает API внешних систем, используя Postman, чтобы лучше разбираться в технических деталях,
🔹 как документировать требования и ставить задачи.

Понимание принципов взаимодействия систем и обмена данными на всех уровнях - ключевой навык для участия в сложных и интересных проектах.

На практическом курсе "Проектирование интеграций" мы разберем все эти темы максимально подробно, чтобы вы могли рассказывать о своих знаниях на примере конкретного проекта и переиспользовать их в своих проектах.

👉 25 часов онлайн-практики в течение 2-х месяцев, где вы задаете вопросы и получаете ответы!
👉 Обратная связь по вашей работе онлайн с экспертами и обратной связью сразу, в моменте: мы даем теорию и пример, вы решаете задачу, и мы даем направление, чтобы у вас всё получалось самостоятельно!

Hard-skills по интеграциям и пониманию базовых принципов архитектуры систем - важнейший шаг для карьеры системного аналитика. Возможность освоить новые навыки на практике 👇

🗓 Предзапись на специальных условиях открыта до 10 декабря

Пример архитектуры MSA для проекта GetDelivery 👀📌 Этот пост надо сохранить!

Для проекта GetDelivery один из вариантов микросервисной архитектуры (MSA) может быть реализован так, как показано на приложенной схеме. Загружайте себе файл с примером и изучайте.

Сразу хочу заметить, что при детальном знакомстве со схемой, чистой микросервисной архитектуры вы не найдёте.

В проектах, с которыми я работала, были такие комбинации:

- Монолит,
- Сервисы,
- Монолит + Сервисы,
- Монолит + Микросервисы,
- Монолит + Сервисы + Микросервисы.
- Сервисы + Микросервисы.


В реальных проектах делают смесь архитектурных подходов. Это нормально.

На приложенной картинке я выделила понятные по требованиям микросервисы, а всё остальное приняла решение отправить в общие сервисы, потому что какой-то специфичной функциональности пока не выделила.

Если будем принимать оплату через нашу систему, то обязательно добавим в GetDelivery интеграционный сервис приема платежей. Интеграция в нем будет с платежной системой.

Кстати, бывает сложно доказать, что микросервис на самом деле микро- 😁 В этом главный подвох микросервисной архитектуры. Когда сервис уже микро-, но ещё не нано-сервис?! 🙈

При проектировании микросервисной архитектуры нужна опытная команда и оптимальные решения, которые принимаются с учетом понимания функциональности всего проекта.

Системные аналитики в процессе проектирования архитектуры помогают разработчикам и архитекторам с пониманием общей картины по функциональности проекта и разъяснением бизнес-потребностей, которые влияют на технические решения.

Какую архитектуру выбрать для проекта? 🧐

🟡 Принятие решений по организации архитектуры системы должно быть обосновано и учитывать не только текущие, но и будущие потребности бизнеса, особенно в контексте нефункциональных требований.


🟡 Нефункциональные требования напрямую влияют на подход к проектированию архитектуры.
Это требования не к тому, что система должна делать, а к тому, как она должна это делать.

Примеры:

+ Система должна сохранять одинаковую скорость отклика при нагрузке до 100 пользователей в 1 сек.

+ Обновление подсистемы интеграции со СДЭК не должно вызывать остановку работы остальных интеграций.

+ Доступность системы должна быть 99% времени в год. То есть допустим простой до 88 часов в год.

+ Время отклика системы на любой запрос не должно превышать 500 миллисекунд, если для него нет интеграций с внешними системами. В случае, если в процессе выполнения запроса принимает участие внешняя система, то время отклика может быть выше, и зависит от времени ожидания ответа от неё.



🟡 Процесс принятия решений по архитектуре проекта:

1. Собираем требования: узнаем у бизнеса, что от системы ожидают.

2. Анализируем требования: понимаем, какие есть ограничения и возможности, продумываем и согласуем бизнес-требования, функциональные и нефункциональные требования.

3. Выбираем архитектуру: определяем, какой тип архитектуры подходит под задачи.

4. Выделяем компоненты, которые будут решать задачи системы и выполнять её функции, а затем отражаем решения на схеме архитектуры.

5. Идем далее на этап детализации требований.


Продолжение 👇

Какой тип архитектуры выбрать? 🙄

🔺 Монолит:
Как один большой блок. Подходит для маленьких проектов и стартапов. Такие системы просты в реализации, но их сложно менять и развивать. Это может быть плохое решение при наличии строгих нефункциональных требований: скорость работы, нагрузки, масштабируемость и другие.

🔺 SOA (Сервисно-ориентированная):
Разбивает систему на несколько крупных частей.
Подход хорош для больших продуктов, где много разных сервисов и нужно распределять нагрузку, делать независимые обновления с возможностью останавливать работу отдельных блоков функциональности, при необходимости.

🔺 Микросервисы:
Много маленьких сервисов, каждый делает что-то одно - выполняет свою микро-задачу.
Удобно, когда надо часто менять или добавлять новую функциональность, при этом держать всю систему в рабочем состоянии по максимуму.
Часто применяется в банковских проектах и высокопроизводительных системах с кучей расчетов в режиме реального времени.
При всех преимуществах в масштабировании, обслуживании и сопровождении, такая архитектура может быть избыточна в системах без высокой нагрузки и высокой чувствительности к данным.
Также есть сложности в синхронизации данных. между разными БД.


И моё любимое ❤️:
Выбор подхода к архитектуре зависит от проекта. Для GetDelivery подойдет и сервисная, и монолитная архитектура.

Микросервисная будет избыточна, т.к. сделает стоимость проекта дороже, но плюсов не принесёт, а только усложнит логику работы системы.

Но т.к. я не хочу держать интеграции и основную логику приложения в одном месте, то я выберу SOA-подход для нашего проекта - с сервисной архитектурой.

Тяжело быть IT-ишником, знаете 😅

Всем отличного настроения на трудовую неделю! Пусть работа будет в удовольствие 😘

Коллеги, всем привет!

Мы с вами завершили верхнеуровневое проектирование архитектуры GetDelivery. Я показала только ту часть проекта, которая касается интеграций с системами доставки. Можно было бы добавить ещё интеграции с системами уведомлений, очереди сообщений (rabbit, kafka), но мы, в контексте текущей задачи, их разбирать не будем. Выбран SOA (сервисно-ориентированный подход) - интеграции вынесены в отдельный сервис.

То, как сейчас отображена схема архитектуры - это моя нотация CR (CloudRectangle).

Пока я намеренно упустила часть обозначений, которые обычно использую:

- Виды API, по которым осуществляется взаимодействие между системами (REST, SOAP, и другие).

- Виды СУБД (SQLite, PostgreSQL, MongoDB и другие).
Но на первом подходе для выбора архитектуры этого достаточно.


Как системный аналитик, я считаю, что понятность и наглядность ценнее нотации. Поэтому в процессе проектирования, по договоренности с командой, могу использовать свою нотацию CR, которую также объясняю на программе по проектированию интеграций вместе с общепринятой нотацией архитектуры С4.

Я с огромным уважением отношусь к авторам стандартов и стараюсь их придерживаться во всех своих схемах. Знания UML и С4 - это фундаментальные знания, на которые я опираюсь в процессе создания любых диаграмм и схем.

Я хочу показать для вас как будет переведена наша схема в общепринтую международную нотацию, про которую могут спрашивать специалистов на собеседованиях. Это C4 - нотация моделирования архитектуры.

Нотация C4 (Model for Software Architecture) — это метод визуализации архитектуры программного обеспечения, разработанный Саймоном Брауном.

Название "C4" расшифровывается как "Context, Containers, Components, and Code". Эти четыре "C" представляют четыре уровня абстракции, которые используются в этой нотации для визуализации и описания архитектуры.

C4 появилась как реакция на сложность и непонятность традиционных архитектурных диаграмм. Саймон Браун предложил этот подход в начале 2010-х годов с целью упростить понимание архитектуры для всех участников команды разработки, включая обычных разработчиков, тестировщиков, аналитиков, менеджеров и других заинтересованных сторон.

Уровни Представления:


🔺 Уровень системы (System Context diagram)

Показывает, как система взаимодействует с внешними сущностями (пользователями, внешними системами). Сразу видно интеграции.

Обычно используют на начальных этапах проектирования, для понимания общего контекста.

Элементы:
- системы,
- пользователи,
- взаимосвязи.


🔺 Уровень контейнеров (Container diagram)

Описывает верхнеуровневую архитектуру и технологии.
Используется для понимания технологического стека и разделения зон ответственности.

Элементы:
- контейнеры (например, веб-приложения, базы данных),
- взаимосвязи,
- технологии.


🔺 Уровень компонентов (Component diagram)

Детализирует структуру внутри контейнера системы, т.е. описывает более детально только один контейнер из предыдущего уровня.

Используется для проектирования и документирования внутренней структуры компонентов системы.

Элементы:
- компоненты,
- взаимосвязи,
- технологии,
- зависимости.


🔺 Уровень кода (Code diagram)

Показывает детали реализации отдельных компонентов.

Используется для документирования структуры кода. На практике не используется, т.к. разработчикам это не надо. Это как диаграмма классов UML: вроде полезно понимать, а по факту не нужна.

Элементы:
- классы,
- интерфейсы,
- отношения между ними.


❤️ Красивая схема C4 в Miro c примером проекта.