• Що повинен знати менеджер проекту та бізнес аналітик про архітектуру ПЗ

    Що повинен знати менеджер проекту та бізнес аналітик про архітектуру ПЗ

Що повинен знати менеджер проекту та бізнес аналітик про архітектуру ПЗ

Архітектура програмного забезпечення — це сукупність рішень про організацію програмної частини системи, яка ґрунтується на виборі структурних елементів, поєднанні обраних елементів та створення напрямку розробки. У реальних проектах ПМ і БА не задають шлях того, як розроблятиметься ПЗ. Даними питаннями займається або архітектор ПЗ, або технічний лідер, який вибирає технології, будує парадигми та стежить за їх виконанням.Але все ж таки ПМ і БА корисно знати, який тип архітектури використаний, щоб розуміти, про що говорять програмісти і які проблеми вони вирішують. Розглянемо найпопулярніші типи архітектури ПЗ.

Типи архітектури ПЗ

Клієнт-серверна архітектура (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 принципів проектування, які покликані зробити проекти більш зрозумілими, гнучкими та зручними у підтримці.

  1. Принцип єдиної відповідальності (Single Responsibility Principle): Кожен клас має мати лише одну причину для зміни.
  2. Принцип відкритості/закритості (Open/Closed Principle): Програмні сутності мають бути відкриті для розширення, але закриті для змін.
  3. Принцип підстановки Лісков (Liskov Substitution Principle): Об’єкти в програмі можна замінити їхніми підтипами без зміни правильності виконання програми.
  4. Принцип розділення інтерфейсу (Interface Segregation Principle): Багато специфічних інтерфейсів краще, ніж один універсальний.
  5. Принцип інверсії залежностей (Dependency Inversion Principle): Модулі вищого рівня не повинні залежати від модулів нижчого рівня. Обидва типи модулів повинні залежати від абстракцій.

Радимо вам наш технічний словник бізнес-аналітика, для того, щоб найголовніша інформація завжди була під рукою.

Більше про архітектуру ПЗ, а також багато іншого ви можете дізнатися на нашому онлайн-курсі Online Technical Skills for PMs and BAs

Sign up for our newsletter
Get the latest info with our monthly newsletter