Найважливіші архітектурні шаблони, які необхідно знати

Архітектурний шаблон - це узагальнене рішення   поширеної проблеми в архітектурі програмного забезпечення в заданому контексті.

Шаблон - це вирішення завдання в певному контексті.

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

Що ж, давайте розбиратися!

• Багаторівнева архітектура

• Канали і фільтри

• Клієнт - сервер

• Модель - представлення - контролер

• Керована подіями архітектура

• Архітектура на основі мікросервісів

Багаторівнева архітектура

Найпоширеніший архітектурний шаблон - багаторівнева архітектура (або «n-рівнева»). Вона добре відома більшості архітекторів, проєктувальників і розробників. Обмежень за кількістю і типом рівнів ніяких немає, проте в більшості випадків така архітектура складається з чотирьох рівнів: представлення даних, бізнес-логіка, зберігання даних і база даних.

Контекст

У будь-яких складних системах необхідно забезпечувати незалежну розробку і розвиток окремих частин. Тому розробникам системи треба зрозумілий і добре задокументований поділ завдань, щоб модулі системи можна було розробляти і підтримувати незалежним чином.

Завдання

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

Рішення

Щоб домогтися такого поділу, при використанні багаторівневого шаблону, програмне забезпечення поділяється на сутності, звані рівнями. Кожен рівень - група модулів, що надають взаємопов'язаний набір сервісів. Їх застосування має бути односпрямованим. Рівні повністю поділяють ПО, причому кожна частина доступна через публічний інтерфейс.

• Перша ідея полягає в тому, що у кожного з рівнів є певні роль і відповідальність. Наприклад, рівень представлення даних відповідає за обробку всього призначеного для користувача інтерфейсу. Такий поділ завдань в багаторівневій архітектурі спрощує формування ефективних ролей і відповідальності.

• Друга ідея полягає в тому, що шаблон багаторівневої архітектури є технічне поділ - на відміну від поділу по доменах: тобто, це групи компонентів, а не домени.

• І, нарешті, третя ідея: кожен рівень позначається як закритий або відкритий. Запит, переміщаючись з рівня на рівень і минаючи закритий рівень, повинен обов'язково пройти через нього - пропустити закритий рівень не можна.

Недоліки

Наявність рівнів знижує продуктивність. Цей шаблон не підходить для високопродуктивних застосунків: проходити кілька рівнів архітектури для виконання бізнес-запиту - це неефективно.

Крім того, додавання рівнів збільшує повну вартість і ускладнює систему.

Застосування

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

Багаторівневий шаблон

Контекст

При розподіленому розгортанні часто необхідно розділити інфраструктуру системи на окремі підмножини.

Завдання

Як розділити систему на ряд незалежних в обчислювальному відношенні виконавчих структур - груп програмного і апаратного забезпечення, об'єднаних яким-небудь засобом зв'язку?

Рішення

Виконавчі структури багатьох систем організовані як набір логічних груп компонентів. Кожна група називається ярусом.

Недоліки

Значні повна вартість і складність.

Застосування

Використовується в розподілених системах.

Канали і фільтри

Один з шаблонів які часто використовувуються  в архітектурі ПО - шаблон каналів і фільтрів.

Контекст

Часто в системах необхідно перетворювати потоки дискретних елементів даних від введення до виводу. На практиці багато типів перетворень повторюються неодноразово, тому бажано зробити з них незалежні компоненти які можна повторно використовувати.

Завдання

Такі системи необхідно розділяти на повторно використовувані слабо пов'язані компоненти з простими узагальненими механізмами взаємодії - таким чином їх можна буде зручно поєднувати один з одним. Слабо пов'язані компоненти з узагальненою взаємодією легко використовувати повторно. А оскільки вони незалежні, їх виконання можна запускати паралельно.

Рішення

У цій архітектурі фільтри пов'язані між собою комунікаційними каналами. Перша ідея полягає в тому, що кожен з каналів з міркувань продуктивності має тип «точка - точка» і є односпрямованим: приймає вхідні дані від одного джерела і направляє вихідні дані в приймач.

У такому підході виділяють фільтри чотирьох видів:

• генератор (source) - відправна точка процесу;

• перетворювач (map) - виконує перетворення деяких або всіх даних;

• випробувач (reduce) - перевіряє один або кілька критеріїв;

• споживач (sink) - кінцева точка.

Недоліки

Чи не найкращий вибір для інтерактивних систем, оскільки така архітектура орієнтована на перетворення даних.

Надмірне використання синтаксичного аналізу і синтезу знижує продуктивність і ускладнює написання самих фільтрів.

Застосування

Архітектура каналів і фільтрів застосовується в найрізноманітніших застосунках, особливо при вирішенні завдань, що забезпечують просту односторонню обробку - наприклад, інструменти EDI (електронний обмін даними), ETL (витяг, перетворення і завантаження).

Приклад - компілятори: послідовно розташовані фільтри виконують лексичний, синтаксичний, семантичний аналіз і створення коду.

Клієнт - сервер

Контекст

Є загальні ресурси та сервіси, до яких потрібно забезпечити доступ великої кількості розподілених клієнтів, і при цьому необхідно контролювати доступ або якість обслуговування.

Завдання

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

Рішення

У підході «клієнт - сервер» компоненти і сполучні елементи мають певну поведінку.

• Компоненти, звані «клієнтами», відправляють запити компоненту, званому «сервер», і чекають відповіді.

• Компонент «сервер» отримує запит від клієнта і відправляє йому відповідь.

Недоліки

Сервер може бути вузьким місцем щодо продуктивності, а також єдиною точкою відмови.

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

Застосування

Підхід «клієнт - сервер» можна застосовувати в моделюванні частини системи, що має багато компонентів, які відправляють запити (це «клієнти») іншого компонента (це «сервер»), який забезпечує роботу сервісів, - наприклад, онлайн-застосунки (електронна пошта, обмін документами і банківська справа).

Модель - представлення - контролер

Контекст

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

Завдання

Як можна відокремити функціональність призначеного для користувача інтерфейсу від функціональності програми і при цьому забезпечити швидкий відгук на дії користувача і зміни в базових даних програми?

Як створювати, підтримувати і координувати кілька подань призначеного для користувача інтерфейсу при зміні базових даних програми?

Рішення

Шаблон «модель - представлення - контролер» (MVC) розділяє функціональність програми на компоненти трьох видів:

• Модель - містить дані програми.

• Представлення - відображає деяку частину базових даних і взаємодіє з користувачем.

• Контролер - діє як посередник між моделлю і представленням і управляє повідомленнями про зміну стану.

Недоліки

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

Абстракції «модель», «уявлення» і «контролер» можуть не дуже добре підходити в разі деяких наборів інструментів для розробки користувальницького інтерфейсу.

Застосування

Архітектурний шаблон MVC зазвичай використовується в мобільних і веб-застосунках при розробці користувальницьких інтерфейсів.

Керована подіями архітектура

Контекст

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

Завдання

Створити розподілені системи, які можуть обслуговувати  асинхронні повідомлення, пов'язані з подією, і масштабироваться в широкому діапазоні величини і складності.

Рішення

Розгорнути незалежні процеси або обробники для роботи з подіями. Прибуваючі події ставляться в чергу. Планувальник витягує події з черги і передає їх до відповідного обробник подій згідно з політикою планування.

Недоліки

Можливі проблемні області - продуктивність і відновлення після помилок.

Застосування

Застосунок для електронної комерції який використовує цей підхід і може працювати наступним чином:

• Сервіс «Замовлення» створює Замовлення в стані очікування і публікує подію «Створено Замовлення» OrderCreated.

• Сервіс «Покупці» отримує подію і намагається зарезервувати кредит для цього замовлення. Потім він публікує подію «Кредит зарезервовано» CreditReserved або «Перевищено Ліміт Кредиту» CreditLimitExceeded.

• Сервіс «Замовлення» отримує цю подію від сервісу «Покупці» і змінює стан замовлення на «Затверджено» або «Скасовано».

Архітектура на основі мікросервісов

Контекст

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

Завдання

При необхідності оптимального використання розподілених ресурсів (наприклад, в хмарних середовищах) монолітні застосунки можуть виявитися занадто великими і складними для ефективної підтримки та розгортання.

Рішення

Створення застосунків у вигляді наборів сервісів: кожен сервіс розгортається і масштабується незалежно і має власний «кордон», який обслуговується за допомогою API. Різні сервіси можуть писатися на різних мовах програмування, управляти власними базами даних і розроблятися різними командами.

Недоліки

Системи повинні бути спроєктовані так, щоб витримувати збої в роботі сервісів, а це вимагає  ретельнішого моніторингу систем. Додаткові витрати ресурсів на організацію роботи сервісів і взаємодії подій.

Крім того, буде потрібно більше пам'яті.

Застосування

Архітектура мікросервісов застосовна в багатьох випадках, особливо коли використовується великий конвеєр даних. Наприклад, мікросервісна архітектура - відмінний вибір для системи звітності про продажі в роздрібних магазинах компанії. Кожен крок у процесі підготовки даних буде оброблятися мікросервісом: збір, очищення, нормалізація, збагачення, агрегація даних, звітність і т. д.

Не так все і складно, правда?

Джерело: levelup.gitconnected.com