Евристика проєктування

По обставинах

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

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

Ця глава об'єднує першу і другу частини. Тут будуть розглянуті евристичні прийоми застосування інструментів аналізу для прийняття різних рішень щодо проєктування програмних засобів, тобто предметно-орієнтованого (бізнесового) проєктування.

Евристика

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

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

Обмежені контексти

Як випливає з матеріалу, засвоєного під час вивчення глави 3, під визначення коректного обмеженого контексту (bounded context) можуть підходити як широкі, так і вузькі межі, охоплювані застосуванням несуперечливого єдиного словника (ubiquitous language).

І все ж який оптимальний розмір обмеженого контексту? Це питання особливо важливе з огляду на часте ототожнення обмежених контекстів з мікросервісами. Чи потрібно завжди прагнути до найменших можливих обмежених контекстів?

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

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

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

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

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

Захист основного піддомену

Така евристика застосовується в основному до обмежених контекстів, що охоплюють основні піддомени (core subdomains), оскільки як універсальні (generic), так і допоміжні (supporting) підобласті вирізняються більшою сформульованістю та гіршою мінливістю.

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

Це можуть бути інші основні, або навіть допоміжні, або універсальні підобласті.

Вибір патерну реалізації бізнес-логіки

У главах 5–7 було розкрито чотири різних способи моделювання бізнес-логіки:

• Транзакційний сценарій (transaction script)
• Активна запис (active record)
• Модель предметної області (domain model)
• Модель предметної області, заснована на подіях (event-sourced domain model)

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

Модель предметної області та її варіант, модель предметної області, заснована на подіях, більше підходять для основних (core) піддоменів.

Евристика вибору патерну

Щоб обрати відповідний патерн, дайте відповіді на наступні питання:

Цю евристику можна візуалізувати за допомогою дерева рішень:

Складна vs Проста логіка

Ще одна евристика — хитромудрість єдиної мови. Що в основі: опис CRUD-операцій чи опис складних бізнес-процесів?

Вибір патерну — це також спосіб перевірки припущень про тип піддомену. Якщо піддомен вважається основним, але йому підходить активна запис, можливо, це не основний піддомен.

Архітектурні патерни

Вибір патерну реалізації бізнес-логіки спрощує вибір архітектури:

• Event-Sourced Domain Model потребує CQRS.
• Domain Model вимагає Портів і адаптерів.
• Active Record найкраще поєднується з Багаторівневою архітектурою з додатковим сервісним шаром.
• Transaction Script може бути реалізований з мінімальною Багаторівневою архітектурою (3 рівні).

Стратегія тестування

Патерни логіки та архітектури визначають стратегію тестування.

1. Піраміда тестування

Акцент на модульних тестах. Найкраще підходить для Domain Model (і Event-Sourced), де агрегати та об'єкти-значення є ідеальними компонентами для тестування.

2. Ромб тестування

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

3. Перевернута піраміда

Акцент на наскрізних (end-to-end) тестах. Підходить для Transaction Script, де логіка проста, а кількість рівнів мінімальна.

Дерево тактичних проєктних рішень

Об'єднавши попередні евристики, отримаємо повну картину:

Висновок

Завдання

::steps 2. Якими будуть проєктні рішення для модуля управління зміною співробітників WolfDesk? ::

::steps 3. Реалізація інтеграції із зовнішнім постачальником свят. Які патерни обрати? ::

::steps 4. Які ще аспекти можна включити в евристичне дерево рішень? ::