Я, Товма Олег, автор і спів-викладач курсу Технічних навичок для бізнес аналітиків, системний і бізнес аналітик, колишній розробник.
У цій статті хочу поділитися знаннями про архітектуру програмного забезпечення і як ми можемо використовувати ці знання у своїй роботі.
Зміст
Архітектура програмного забезпечення
Перш за все, почнемо з базової термінології.
Архітектура програмного забезпечення (ПЗ) — це план або структура, яка описує, як система організована, як різні її частини (компоненти) взаємодіють між собою та з зовнішніми системами.
При побудові архітектури використовуються архітектурні шаблони, які дозволяють використовувати найкращі практики вирішення архітектурних проблем. Це як план будинку, де є стіни, кімнати, двері та вікна, але замість будівельних матеріалів ми працюємо з кодом, базами даних і серверами.
Архітектура важлива, тому що від неї залежить, як система працює, наскільки вона стабільна, гнучка, безпечна та готова до розвитку в майбутньому.
З розвитком ІТ сфери і продуктів, формувались і підходи до побудови архітектури ПЗ.
Розглянемо основні типи архітектури ПЗ, які на сьогодні активно використовуються.
Монолітна архітектура
Монолітна архітектура означає, що вся програма складається з єдиного блоку коду, де всі частини взаємодіють прямо одна з одною. Якщо це велика програма, у ній є всі можливості та функції в одному місці.
Приклад: Уявіть, що у вас є бухгалтерський застосунок для малого бізнесу, який включає функції для ведення фінансових записів, створення звітів, управління рахунками, обліку витрат і прибутків. Монолітна архітектура в цьому випадку означає, що весь функціонал програми знаходиться в одному кодовому блоці, який розгортається як єдине ціле. Це означає, що всі функції — від інтерфейсу користувача до бази даних — інтегровані в одну програму.
Плюси:
Простота розробки, особливо на початку.
Легше тестувати та запускати програму, оскільки вона одна ціла.
Чітке уявлення про всі взаємозв'язки в програмі.
Мінуси:
Зі зростанням системи код стає громіздким і важким для підтримки.
Зміна однієї частини може вплинути на інші частини, що може призвести до помилок.
Складно масштабувати окремі функції системи.
Шаблон "Шари (Layers)"
Цей шаблон розділяє систему на кілька шарів, де кожен шар відповідає за певну функціональність. Наприклад:
Презентаційний шар (інтерфейс користувача)
Логічний шар (бізнес-логіка)
Шар доступу до даних (робота з базою даних)
Мікросервісна архітектура
Мікросервісна архітектура поділяє систему на багато дрібних автономних частин (мікросервісів), де кожен виконує окрему функцію. Це фактично міні-програми. Ці частини взаємодіють між собою через спеціальні протоколи (наприклад, через API).
Приклад: Інтернет-магазин в такій архітектурі може мати окремий мікросервіс для управління товарами, інший для обробки замовлень і ще один для роботи з користувачами. Всі вони працюють незалежно один від одного, але разом забезпечують функціонування магазину.
Плюси:
Легше масштабувати окремі частини системи.
Можна оновлювати або змінювати один мікросервіс, не торкаючись інших.
Простота в підтримці великих команд розробників, кожна з яких може працювати над своїм мікросервісом.
Мінуси:
Складність у налаштуванні взаємодії між мікросервісами.
Потрібно добре продумувати тестування і безпеку, оскільки система складається з багатьох частин.
Ускладнене управління інфраструктурою, оскільки кожен мікросервіс потребує окремих ресурсів.
Шаблон "Gateway/Facade" (Шлюз/Фасад)
У цьому шаблоні єдиний шлюз (API Gateway) відповідає за взаємодію між клієнтом і набором мікросервісів. Клієнт не звертається до мікросервісів напряму, а використовує шлюз, який розподіляє запити.
Шаблон "Database per Service" (Окрема база даних для кожного сервісу)
Кожен мікросервіс має власну базу даних і відповідає за свій набір даних.
Клієнт-серверна архітектура
Ця архітектура складається з двох частин: клієнт (зазвичай це те, що бачить користувач — наприклад, браузер) і сервер (місце, де зберігаються дані і виконується основна логіка).
Приклад: Банківська програма. Клієнт — це мобільний додаток на телефоні, а сервер — це комп'ютери банку, де зберігаються рахунки та обробляються транзакції.
Плюси:
Чітке розділення на частини: клієнт для взаємодії з користувачем, сервер для обробки даних.
Сервер можна легко оновлювати і змінювати, не зачіпаючи клієнт.
Мінуси:
Якщо сервер виходить з ладу, клієнт не може працювати.
Клієнт і сервер повинні постійно взаємодіяти, що може створювати проблеми з продуктивністю або з'єднанням.
Шаблон "Proxy" (Проксі-сервер)
Проксі — це проміжний сервер, який приймає запити від клієнта і передає їх на сервер. Проксі може кешувати відповіді або контролювати доступ.
Подійно-орієнтована архітектура (Event-driven architecture)
Ця архітектура побудована навколо подій — маленьких повідомлень, що відправляються, коли щось відбувається в системі. Різні компоненти (сервіси) реагують на ці події. Приклад: У системі електронної пошти подія може бути "новий лист", після чого система відправляє повідомлення користувачеві, зберігає лист в базі даних і додає до статистики.
Плюси:
Висока продуктивність, оскільки сервіси реагують на події тільки тоді, коли вони відбуваються.
Легко масштабувати та розширювати, додаючи нові обробники подій.
Мінуси:
Важче тестувати та відстежувати всі події.
Якщо події обробляються неправильно, це може створити "хаос" у системі.
Шаблон "Event Sourcing" (Джерело подій)
У цьому шаблоні всі зміни в системі представляються у вигляді подій, що записуються в журнал подій. Це дозволяє відновити поточний стан системи на основі попередніх подій.
Сервіс-орієнтована архітектура (SOA)
SOA — це архітектура, де всі частини системи представлені у вигляді незалежних сервісів, які можуть обмінюватися даними один з одним. Це схоже на мікросервісну архітектуру, але орієнтоване на більші сервіси.
Приклад: Велика корпорація може мати різні системи для управління фінансами, клієнтами, товарами, і всі ці системи можуть взаємодіяти через стандартизовані сервіси.
Плюси:
Гнучкість у використанні різних технологій і мов програмування для різних сервісів.
Можливість перевиконання сервісів, що зменшує дублювання логіки.
Мінуси:
Складна інтеграція та налаштування комунікацій між сервісами.
Важче забезпечувати узгодженість даних між різними сервісами.
Шаблон "Service Registry" (Реєстр сервісів)
Цей шаблон передбачає наявність центрального каталогу, в якому зберігаються всі доступні сервіси. Системи можуть звертатися до реєстру, щоб знайти потрібний сервіс.
Відмінності між типами архітектури програмного забезпечення
Моноліт — це один великий блок коду, в той час як мікросервіси складаються з дрібних автономних частин. Мікросервіси дозволяють легше розділяти та масштабувати програму, тоді як моноліт простіший на початкових етапах.
Клієнт-сервер має чітке розділення між тим, що бачить користувач (клієнт), і тим, що працює на задньому плані(backend, сервер). Мікросервісна і SOA архітектури більше орієнтовані на поділ сервісів, але SOA орієнтується на великі системи, тоді як мікросервіси — на менші й незалежні.
Архітектура обробки подій фокусується на реакції на події, а не на постійному обміні даними між частинами системи, як це відбувається в інших архітектурах.
Для чого бізнес-аналітикам знати архітектурні шаблони
Нам, як аналітикам, розуміння архітектурних шаблонів дозволяє отримати наступні переваги:
Поліпшення комунікації з технічними командами.
Прийняття рішень щодо функціональних і нефункціональних вимог.
Підвищення якості аналізу та прогнозування впливу змін.
Оцінка технічної життєздатності бізнес-рішень.
Управління ризиками і витратами.
Сприяння довгостроковому стратегічному плануванню.
Поліпшення оцінки часу та ресурсів для проєктів.
Вибір архітектури залежить від багатьох факторів: масштабу проєкту, кількості користувачів, необхідності масштабування та розширення, і навіть технологічних можливостей команди. Кожен тип архітектури має свої плюси і мінуси, і найкраща архітектура — це та, що відповідає конкретним вимогам вашої системи.
Архітектурні шаблони — це готові рішення для повторюваних проблем, які зустрічаються при розробці програмного забезпечення і шаблони допомагають організовувати структуру і взаємодію компонентів в кожному типі архітектури, забезпечуючи гнучкість, масштабованість та ефективне управління ресурсами. Кожен тип архітектури має свої специфічні шаблони, які використовуються для організації взаємодії між компонентами системи.
А щоб дізнатися детальніше про тонкощі архітектури, шаблонів і здобути інші технічні знання – приходьте знайомитись до нас на курс Технічних навичок для бізнес аналітиків.
Comments