Архітектура програмного забезпечення — це сукупність рішень про організацію програмної частини системи, яка ґрунтується на виборі структурних елементів, поєднанні обраних елементів та створення напрямку розробки. У реальних проектах ПМ і БА не задають шлях того, як розроблятиметься ПЗ. Даними питаннями займається або архітектор ПЗ, або технічний лідер, який вибирає технології, будує парадигми та стежить за їх виконанням.Але все ж таки ПМ і БА корисно знати, який тип архітектури використаний, щоб розуміти, про що говорять програмісти і які проблеми вони вирішують. Розглянемо найпопулярніші типи архітектури ПЗ.
Типи архітектури ПЗ
Клієнт-серверна архітектура (Client–server architecture)
Клієнт-серверна архітектура — це мережева архітектура, в якій навантаження розподілене між постачальником та замовниками послуг, які називаються сервером та клієнтами.
Розглянемо, як відбувається взаємодія клієнтів та сервера, на прикладі інтернет-магазину:
- Користувач відкриває браузер та заходить на сайт магазину.
- Вибирає товар або робить будь-які інші дії та натискає кнопку “Proceed” для підтвердження бажаної дії.
- Від клієнта, яким може виступати мобільний девайс, ПК, лептоп та інший пристрій, надсилається запит на сервер, де опрацьовується вся бізнес-логіка для забезпечення виконання цієї операції.
Перевага такого типу архітектури полягає в наявності одного або декількох централізованих серверів, які мають велику обчислювальну потужність. Це дозволяє їм виконувати величезний обсяг роботи, клієнт же при цьому не навантажений — він отримує тільки готову запитувану інформацію.
Всупереч поширеній хибній думці, клієнт-серверний додаток — це не лише веб-програма. На такій архітектурі можуть бути побудовані і мобільні та десктоп додатки.
До недоліків клієнт-серверної архітектури відноситься наявність протоколу комунікації та обов’язкова участь сервера, навіть якщо користувачеві потрібно виконати завдання в межах свого пристрою. Наприклад, побудова на клієнт-серверній архітектурі Microsoft Word означала б постійні затримки в роботі, тому що для виконання будь-якої дії було б потрібне відправлення запиту на сервер і очікування відповіді від нього.
Багаторівнева архітектура (Multitier architecture)
Багаторівнева архітектура — клієнт-серверна архітектура, в якій розділяється функціонал представлення, обробки та зберігання інформації.
Найбільш популярною є трирівнева архітектура, що включає такі складові:
- Подання контенту кінцевому користувачеві.
- Бізнес-логіка.
- Дані додатка.
Які переваги побудови програми за рівнями? По-перше, це дозволяє різним командам проводити розробку на різних рівнях. По-друге, зміни одного рівня не вплинуть на інші. По-третє, у разі потреби масштабування, можливо масштабувати один рівень, а не весь додаток.
Монолітна архітектура (Monolithic architecture)
Монолітна архітектура — модель проектування програмного забезпечення, яка передбачає функціонування програми як окремого модуля, автономного від інших програм.
На прикладі того ж інтернет-магазину можна пояснити суть цього поняття так: весь функціонал, включаючи логін, пошук та купівлю товару, залишення відгуку, зосереджений в одному додатку, який розміщується на одному сервері. Такий додаток самодостатній — він має всі необхідні рівні (дані, бізнес-логіка, UI).
З одного боку, це дає свої переваги — розробка буде вестися швидко, тому що вся кодова база знаходиться під рукою і програмісти не гаятимуть часу на читання документації. Але з іншого боку, масштабування монолітних додатків є дуже витратним, а розгортання на сервері може бути занадто тривалим.
Подійно-орієнтована архітектура (Event-driven architecture, EDA)
Архітектура ПЗ, керована подіями, — це шаблон, який дозволяє створювати, визначати, споживати та реагувати на події.
Виділяють такі його складові:
- продюсер події — це її початковий відправник;
- споживачі події — це сторона, що її приймає;
- приймання подій.
Повернемося до прикладу інтернет-магазину. Після входу на сайт користувач генерує якусь подію (входить до облікового запису, купує товар тощо), тобто виконує роль продюсера подій. Потім споживач події приймає її та реагує будь-якою дією (наприклад, перенаправляє користувача на наступну сторінку).
Подійно-орієнтований підхід допомагає забезпечувати стратегію відсутності жорсткої зв’язаності між сервісами.
Сервіс-орієнтована архітектура (Service-oriented architecture, SOA)
Сервіс-орієнтована архітектура призначена для здешевлення обслуговування монолітів і є модульним підходом до розробки ПЗ, заснованим на використанні слабко пов’язаних між собою, взаємозамінних компонентів.
У випадку інтернет-магазину цей підхід реалізується так. Користувач заходить на сайт та вводить свої облікові дані. Певний сервіс перевіряє, чи достатньо у користувача повноважень, щоб увійти в цей профіль. При натисканні кнопки “Купити” різні сервіси перевіряють, чи є товар у наявності, чи достатньо на карті коштів на оплату тощо.
У всіх цих сервісів може бути єдина база даних і вони можуть працювати з одними ресурсами.
Перевага цього підходу – модулі, які ми можемо перевикористовувати. До мінусів же можна віднести:
- Складність влаштування так званої сервісної шини підприємства — сполучного ПЗ, завдання якого полягає в знаходженні потрібного сервісу, забезпеченні стійкості до відмов і рівномірному розподілі навантаження.
- Проблематичність горизонтального масштабування через загальну базу даних та збільшення навантаження на неї.
- Слабка відмовостійкість — якщо відбувається збій в сервісній шині підприємства, припиняє працювати весь додаток.
Архітектура мікросервісів (Microservices)
Архітектурний стиль мікросервісів — підхід побудови системи на основі незалежних, самодостатніх сервісів, призначених для виконання конкретного завдання.
Тобто в нашому інтернет-магазині буде окремий сервіс, який відповідає за кожну дію, наприклад, за здійснення покупки. У нього буде своя база даних та її ресурси будуть ізольовані від ресурсів інших сервісів.
Перевага рхітектури мікросервісів:
- Підвищення відмовостійкості — якщо не працює один сервіс, це ніяк не впливає на інші.
- Використання легких протоколів: HTTP, REST, Thift API замість сервісної шини підприємства.
- Легкість горизонтального масштабування.
- Усі послуги розгортаються на окремих серверах — розробкою кожного з них можуть займатися різні команди.
Останній пункт можна також віднести і до недоліків підходу, оскільки така розробка досить дорога і складна. Тому її рідко застосовують для створення простих програм.
CQRS
The Command and Query Responsibility Segregation — підхід до проектування ПЗ, при якому код, що змінює стан, відокремлюється від коду, що читає цей стан.
У цьому підході виділяють Queries — дії, що не змінюють стан об’єкта, і Commands — дії, що змінюють об’єкт. Підтримувати цю архітектуру досить складно, оскільки доводиться постійно контролювати, чи відбувається зміна стану об’єкта.
Щодо переваг цієї архітектури, це простота як вертикального, так і горизонтального масштабування завдяки незалежності операцій читання та запису інформації.
Застосовується CQRS переважно створення високонавантажених систем. У випадку з невеликим додатком інвестиції в розробку значно перевищать одержану від неї вигоду.
Підсумуємо
У програмній інженерії існує 5 принципів проектування, які покликані зробити проекти більш зрозумілими, гнучкими та зручними у підтримці.
- Принцип єдиної відповідальності (Single Responsibility Principle): Кожен клас має мати лише одну причину для зміни.
- Принцип відкритості/закритості (Open/Closed Principle): Програмні сутності мають бути відкриті для розширення, але закриті для змін.
- Принцип підстановки Лісков (Liskov Substitution Principle): Об’єкти в програмі можна замінити їхніми підтипами без зміни правильності виконання програми.
- Принцип розділення інтерфейсу (Interface Segregation Principle): Багато специфічних інтерфейсів краще, ніж один універсальний.
- Принцип інверсії залежностей (Dependency Inversion Principle): Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Обидва типи модулів повинні залежати від абстракцій.
Радимо вам наш технічний словник бізнес-аналітика, для того, щоб найголовніша інформація завжди була під рукою.
Більше про архітектуру ПЗ, а також багато іншого ви можете дізнатися на нашому онлайн-курсі Online Technical Skills for PMs and BAs.
