Onion архітектура

Onion архітектура: Структура та застосування

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

Основні рівні Onion архітектури

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

1. Рівень взаємодії (Interaction Layer)

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

2. Галузь (Domain)

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

3. Мова (Language)

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

Основні правила Onion архітектури

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

2. Рівні спрямовані до центру. Зовнішні шари можуть викликати функції внутрішніх шарів, але не навпаки.

3. Ізоляція рівнів. Кожен шар повинен знати лише про той, що знаходиться ближче до центру, без жодних зворотних залежностей.

Переваги Onion архітектури

• Чітка сегментація відповідальності. Завдяки поділу на окремі шари, легше підтримувати і тестувати бізнес-логіку.

• Захист домену від інфраструктурних змін. Можна змінювати способи збереження даних або інтеграції із зовнішніми системами без впливу на основну логіку.

• Гнучкість та розширюваність. Легко додавати нові рівні взаємодії або змінювати поточні, не порушуючи загальну архітектуру.

Практичний приклад

Один із способів відрізнити доменну логіку від взаємодії — це звернути увагу на використовувані терміни. Якщо у вашому коді з’являються бізнес-терміни, такі як product, image, price, або discount, це вказівка, що ви працюєте з доменом. Проте логіка повторних запитів на сервер чи кешування вже належить до шару взаємодії.

function getWithRetries(url, retriesLeft, success, error) {
  if (retriesLeft <= 0) {
    error('No more retries')
    return
  }

  ajaxGet(url, success, function (e) {
    getWithRetries(url, retriesLeft - 1, success, error)
  })
}

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

Посилання:

Eric, N. (2021). Grokking Simplicity. Manning.