Що я змінила б, якби починала DDD-проєкт знову

Коли я починала працювати з DDD серйозніше, найбільше хотілося зробити "правильно" з першого разу.

Знайти всі bounded contexts, одразу вибрати правильні abstraction, розкласти код по шарах, визначити repository, entities, value objects і services.

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

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

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

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

Тепер я б сприймала початкові bounded contexts як робочі гіпотези, а не як остаточну карту системи.

Раніше я часто починала з use case: що натискає користувач, який endpoint викликається, які таблиці треба змінити.

Тепер я б набагато раніше ставила просте питання: що в системі не має права стати неправдою після завершення операції?

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

У матеріалі про те, де має жити бізнес-правило я розбирала різницю між controller, service і domain model.

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

Це особливо важливо для правил, які викликаються з HTTP, queue, command або cron. Якщо правило залежить від контролера, воно майже напевно стоїть не там.

DDD легко провокує на створення великої кількості "правильних" класів: interfaces, repositories, factories, mappers, services.

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

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

Саме тому я більше не створюю repository для кожної моделі. У матеріалі про те, коли Repository справді потрібен у Laravel DDD я описувала Repository як межу стійкості для aggregate, а не як обов’язкову обгортку над Eloquent.

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

Коли для адміністративної таблиці починаєш тягнути aggregate, додавати relation лише заради колонок і будувати складні eager loading, це вже хороший сигнал.

У матеріалі про Read Model у DDD я писала, що read side може мати власну форму даних без порушення DDD.

Якби я починала знову, я б дозволила собі окремий query object або Read Model раніше.

Laravel дуже природно підштовхує мислити таблицями: model, migration, relation, foreign key.

Для CRUD це часто чудово. Але в DDD таблиця не завжди дорівнює entity, а foreign key не визначає межу агрегату.

Якби я починала знову, я б спочатку описувала поведінку словами предметної області, а вже потім вирішувала, як це зберігати.

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

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

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

Коли модель будується від ORM, дуже легко додати relation в обидві сторони просто тому, що це можливо.

Але доменній моделі не завжди потрібно знати всі сусідні сутності.

Менша кількість зв’язків часто робить агрегат простішим, а залежності явнішими.

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

Такі тести також швидше показують, чи ми розуміємо invariant, чи лише повторюємо поведінку контролера.

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

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

Найгірший варіант для мене тепер не зміна моделі, а збереження старої моделі лише тому, що навколо неї вже побудовано багато структури.

У роботі над Center я поступово прийшла саме до такого підходу.

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

Якби я починала цей шлях знову, я б зробила ці питання центральними раніше.

Я навмисно не переношу сюди внутрішню карту Center. Для цієї статті важливі висновки, а не конкретні модулі.

Я б не робила кілька речей автоматично:

• не намагалася б намалювати всі bounded contexts до появи достатньої кількості сценаріїв;
• не створювала б repository, interface або service тільки тому, що вони "мають бути в DDD";
• не дозволяла б контролерам довго володіти предметними правилами;
• не тягнула б aggregate в кожен список і кожну таблицю;
• не вважала б foreign key доказом спільного aggregate;
• не боялася б змінити ранню модель після нового розуміння предметної області.

Якби я починала DDD-проєкт знову, я б витрачала менше часу на питання "який pattern тут використати?" і більше на питання "яке правило ми зараз захищаємо?".

Менше дивилася б на таблиці як на готову модель. Раніше відділяла б читання. Не вводила б abstraction до появи реальної межі. І дозволяла б bounded contexts змінюватися разом із нашим розумінням.

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