Предисловие
Данная статья скорее написана мной для самого себя что бы помочь разобраться в книге Вона Вернона. По моему скудному мнению хоть в названии книги и фигурирует "Реализация" она не полностью поясняет все детали и понятия которыми оперирует автор. По сути эта статья рецензия + собственные заметки. Отчасти это одна из причин почему я решил написать статью именно тут а не в Notion исключительно для себя, возможно это может помочь следующему читателю более понятно погрузится в прочтение этой книги или более опытные читатели смогут поделится своими замечаниями касательно моих наблюдений.
P.S. Возможно конечно такая статья уже и существует но в ходе моего знакомства чего-то подобного я не нашёл, поэтому ссылки на похожие статьи тоже приветствуются
Первые сложности
Первое с чего хотелось бы начать это конечно, структура книги вплоть до последней главы автор использует понятия и ссылки на последующие главы что ограничивает понимание текста в рамках только личных знаний, именно поэтому я отдельно добавлю пункт заметок с кратким описанием понятия что это и как это.
Вторым усложнением стало конечно же «написание» на мой взгляд местами было много тавтологий а местами просто через чур мудрено. Возможно это связанно с переводом т.к. судя по имени автора он явно не писал изначально книгу на русском.
Но что бы не быть голословным, качестве примера приведу цитату из книги которую я показывал своей жене для того что бы она понимала что такое техническая литература
Модель предметной области будет реализована в явном ОГРАНИЧЕННОМ КОНТЕКСТЕ: контексте оптимальных закупок. Этот ОГРАНИЧЕННЫЙ КОНТЕКСТ однозначно соответствует от дельной ПОДОБЛАСТИ - смысловому ядру оптимальных закупок. Благодаря тому, что он однозначно соответствует одной ПОДОБЛАСТИ, а его модель предметной области тщательно продумана, он является одним из лучших ОГРАНИЧЕННЫХ КОНТЕКСТОВ в этой деловой ПРЕДМЕТНОЙ ОБЛАСТИ
На удивление перечитывая сейчас я с предельной ясностью понимаю что именно имеется тут ввиду но на тот момент для меня это был лишь набор слов
Ну и третий момент который может быть не сразу кристально ясен это книга является не совсем примером реализации скорее это пояснения на примерах. Представьте что всю вашу работу разработчиком а именно: обсуждение бизнес процессов, проектирование этих процессов с архитектурой кода и написание кода бросили в блендер и потом финальный результат подали вам в виде книги. Вот это то что вас встретит. Будте готовы к тому что вам прийдется ловить эти грани где речь идет о верхних уровнях проекта где про код даже знать не хотят а где речь идет о интерфейсах и наследованиях
Основные понятия
Единый язык - Тут как слышится так и пишется. По сути при согласовании общего языка когда к вам придёт задача она будет описана след образом. Нужно что бы Автор(Author) мог редактировать(Edit) книгу(Book). В условиях которые я себе придумал(а по факту мы согласовали и т.п) Я буду четко понимать что книга эта любое произведение автора, под редактированием имеется ввиду изменение текста книги.
Подобласть - Это часть бизнеса отвечающая за себя. Если брать в пример популярный интернет магазин то подобластями будут. ПВЗ, доставка в ПВЗ, каталог товаров и т.п. Каждая из них существует отдельно друг от друга и имеет собственный язык. Например в ПВЗ - заказ это n предметов которые закреплены за покупателем. В доставке - заказ это множество товаров привязанных к конкретному ПВЗ.
Предметная область - это компиляция подобластей которая формирует наш бизнес.
Смысловое ядро - это предметная область, но отличие её заключается в том, что это то что отличает ваш бизнес от остальных. Если вы печете торты то это делают многие, но если в качестве начинки вы используете собственно выращенные ягоды, готовите их по бабушкиному рецепту и вообще у вас торты в виде ботинка то как раз таки это и есть ваше смысловое ядро.
Служебные подобласти - часть вашего бизнеса которая не относится к смысловому ядру но не является отличительной. В рамках тортов это может быть упаковка в коробки.
Неспециализированные подобласти - это область которая так же важна для успеха бизнеса но не имеет первоочередного значения. Продолжая наш пример с тортами. Это может быть доставкой вашей продукции, вам не обязательно везти торт самому, вы просто можете отправить его к клиенту на такси.
Карта контекстов - это то как ваши контексты(области со своим общим языком) связанны друг с другом
Сущности - это какой то уникальный объект который может изменяться в ходе своей жизни в проекте. Самым банальным примером может стать Пользователь или Компания. Обязательным для такого объекта будет являться uid который из себя может представлять набор данных 20241212-CAKE-U-0321fds (В данном случае у нас есть дата создания, проект cake, понимание что это user и uuid). Кстати, если вы подумали что я в БД создам что то вроде
USER
uid |
name |
20241212-CAKE-U-0321fds |
Паша |
То увы это не совсем правильно т.к. uid должен быть создан самим приложением. Но у нас есть еще и ORM и для него нужен суррогатный id который мы используем ка первичный ключ
USER
id |
uid |
name |
1 |
20241212-CAKE-U-0321fds |
Паша |
Объект-значение - это неизменяемый объект. Что это значит ? Нет это не значит что при необходимых изменениях мы должны оставить его где-то на чердаке пылиться. Это значит что объект должен быть защищен от изменений и при необходимости мы его будем пересоздавать.
Кстати наш UID в рамках User отлично может стать объектом значением т.е.
class User {
private UID accountId
}
class UID {
creation_date
department
role
uuid
}Модули - самым простым пояснением будет что это пространство имен
Агрегат - вот тут то мы и приехали. Если сильно упростить понимание этой части то User которого мы создали выше это и есть наш агрегат. По сути это объект который объединяет в себе объекты-значения и сущности в рамках одной области. Это в свою очередь накладывает определенные ограничения т.е. если мы хотим изменить в uid ‘cake’ на ‘pie’ то мы не можем обратится напрямую к uid.department = pie
Мы должны попросить пользователя сменить это значение
user.switchDepartment(‘pie’)
Хранилище - По сути это (Repository и QueryBuilder) + ORM с транзакциями и методами persist и flush. По большей части глава описывает как раз таки варианты того как вы можете организовать хранилище данных
Итог
Как вы могли понять по итогу эта статья никак не объяснит вам что из себя представляет DDD но я надеюсь она сможет стать быстрым справочником что бы что-то освежить в памяти или дать первичное понимание при встрече новых понятий в книге.
В ходе написания наткнулся на полезную статью с более подробным разъяснением
https://habr.com/ru/articles/316438/
https://habr.com/ru/articles/316890/