Чиста архітектура (Роберт Мартін, 2012) узагальнює гексагональну, «цибулеву» та інші подібні архітектури у вигляді концентричних кіл:
┌──────────────────────────────────────────┐
│ Фреймворки й драйвери (веб, БД, UI) │
│ ┌────────────────────────────────────┐ │
│ │ Адаптери (контролери, репозиторії) │ │
│ │ ┌──────────────────────────────┐ │ │
│ │ │ Сценарії (use cases) │ │ │
│ │ │ ┌────────────────────────┐ │ │ │
│ │ │ │ Сутності (бізнес-правила)│ │ │ │
Правило залежностей - головне: залежності в коді спрямовані лише всередину. Внутрішнє коло нічого не знає про зовнішні - ні назв класів, ні функцій, ні форматів даних.
- сутності - найзагальніші бізнес-правила, що існували б і без програми («замовлення не можна оплатити двічі»);
- сценарії використання - правила конкретного застосунку («оформлення замовлення: перевірити залишки, зарезервувати, створити рахунок»);
- адаптери - перетворюють дані між форматом сценаріїв і форматом зовнішніх систем;
- фреймворки й драйвери - Laravel, база, черги, HTTP.
Як виконати правило, якщо сценарію потрібна база? Через інверсію залежностей: сценарій оголошує інтерфейс (OrderRepository), а реалізація в зовнішньому колі його імплементує. Залежність у коді - всередину (адаптер залежить від інтерфейсу ядра), хоча виклик іде назовні.
Що це дає:
- бізнес-правила не залежать від фреймворку - оновлення Laravel чи заміна бази не зачіпає ядро;
- ядро тестується без інфраструктури;
- рішення про технології можна відкладати.
Критика й реальність:
- багато шаблонного коду: DTO на кожній межі, відображення моделей, інтерфейси з однією реалізацією;
- у типовому CRUD-застосунку сценарії тонкі, і накладні витрати не окупаються;
- Laravel побудований навколо протилежної філософії - продуктивність через тісну інтеграцію (Eloquent, фасади, хелпери).
Прагматичний висновок для співбесіди: правило залежностей корисне як принцип навіть без повних «кіл» - бізнес-логіка не повинна залежати від деталей доставки (HTTP-запиту, сесії, формату API). Повну чисту архітектуру варто застосовувати там, де складність предметної області справді переважає технічну.
Докладніше в документації: Robert Martin: The Clean Architecture