Что такое DDD?
Это Предметно-ориентированное проектирование. Копипаст из вики по Domain-Driven Design уверен, чтот тот счастливчик, который провалился в эту статью, и эту задачу сможет решить сам. Или, в крайнем случае, можно почитать на хабре тут.
Моя статья, это скорее рефлексия на наши отношения с DDD, о которых мне пересказывали знакомые знакомых. И, наконец, уже как несколько лет, я участник этих абьюзивных отношений.
Domain-Driven Design - это не про базы данных и не про фреймворки. Это про то, как сделать так, чтобы ваш код не выглядел как набор решений, принятых на затянувшемся ретро.
DDD - это способ проектирования, который ставит бизнес-домен в центр внимания.
DDD - это про то, чтобы ваш код не только работал, но и был понятен людям, которые будут его поддерживать. А это, как вы знаете, не всегда те же самые люди, что его писали.
Анатомия DDD
Ниже я представил концепцию составные части такого проектирования, на примерах своего опыта. Уверен, что такая информация проще, чем засеньёринное определение из вики.
Разделение контекста (Bounded Contexts)
Разделяйте систему на части, чтобы не сойти с ума. Например, в системе интернет-магазина можно выделить контексты "Каталог товаров", "Корзина" и "Оплата". Это поможет избежать ситуации, когда изменение в одном месте ломает всё остальное.
А теперь по человечески, это когда система для кредитов считает вас банкротом из-за долга в 50 рублей, а система лояльности в это же время настойчиво предлагает VIP-карту с "эксклюзивными привилегиями". Они живут в разных контекстах, они разделены, изолированы друг от друга.
Аггрегирование (Aggregates)
Управляйте сложностью, группируя объекты. Например, заказ в интернет-магазине может быть агрегатом, который включает в себя товары, адрес доставки и способ оплаты. Это позволяет работать с заказом как с единым целым.
Единый язык (Ubiquitous Language)
Говорите на одном языке с бизнесом. Если бизнес говорит "клиент", то и в коде должно быть "клиент", а не "user" или, что ещё хуже, "entity". Это кажется очевидным, но вы удивитесь, если чекните свои репозитории, можете найти, что client = user = human.
А сколько проблем может возникнуть из-за несоответствия терминов...
Объект-значение (Entities и Value Objects)
Два базовых строительных блока вашей системы, перепутаете и привет, костыли.
Сущности (Entities) - это объекты с уникальной идентичностью: клиент банка остаётся тем же клиентом, даже если сменил все свои данные от фамилии до номера телефона.
Объекты-значения (Value Objects) - просто наборы данных без идентичности, я бы назвал их "словари' из контекста БД.
Пример, адрес "Москва, ул. Ленина, д. 1" одинаков для любого, кто там прописан. Если вы храните адреса как сущности, то ваша база данных скоро раздуется до размеров HD фильмов с дубликатами на каждом шагу. Типичная ошибка джуниоров - это когда они делают все сущностями, а потом удивляются, почему система тормозит и падает при любой миграции данных.
И что я должен понять из этого?
DDD отлично подходит для сложных систем, где важно понимать, что происходит. Но если вы работаете над простым CRUD-приложением, то, возможно, это не для вас. Не пытайтесь натянуть DDD на глобус - это не универсальное решение.
Послесловие
В последнии пару месяцев, всё чаще на слуху латинские 3 буквы - DDD. При этом, откровенно, мне сложно похвастаться опытом работы с такой архитектурой, где можно выявить все принципы такого подхода в рамках одного проекта. Однако, какие то составные принципы (но не все) такой архитектуры существуют в почти в каждом проекте, с которым мне посчастливилось поработать.
Перед тем, как я решился посмотреть популярность запроса, субъективно, я ощущал DDD - как хайпующий тренд. Но, кажется, мне надо откаллибровать мое суъективные оценки восприятия.
Тема медленно набирала популярность, а сейчас тренд остановился.
Не удивительно, за 5+ лет, эти ИТшники придумали новые слова и могли потерять интерес к этим 3м буквам.
Я думаю, что тема не стала хайпом, поскольку она:
1) Сложная
2) Если не правильно ее понять, можно всё сильно запутать
3) Сеньёристая и модная.
Мне интересно, что думает читатель, у которого хватило терпения дойти до конца - почему тема ddd не хайпует?
Еще одно послесловие - последнее, клянусь
В процессе написания статьи, сбора контекста, рефлексии на тему, сложилось впечатление, что тема DDD проявит себя в других 3х буквах, но в виде более декомпозированного арх подхода. Уж слишком много в этом DDD сложных углеводов =)
