Знаменитая «синяя книга DDD». Читаю её уже в третий раз. Книга из тех, что при каждом прочтении через призму накопленного опыта раскрываются по-новому.
Книга концептуальна. Автор имеет собственную точку зрения (для 2004 года – далеко не тривиальную), и убедительно и с примерами её доказывает и раскрывает. Читается тяжело – много абстракций, сложный язык.
Это книга «отца-основателя»: у автора не было возможности опереться «на плечи титанов» за неимением таковых.
Исходя из современных представлений о DDD книга местами наивна, местами нелогична.
Автора часто критикуют за порядок изложения – мол, сперва нужно было дать специфичные для DDD крупномасштабные шаблоны (которые составляют вторую половину книги), а после этого – мелкомасштабные (первая половина). Но если мелкомасштабные шаблоны (уровня реализации) в 2004 году уже были проработаны (книга «банды четырех» появилась еще в 1994 году), то крупномасштабные шаблоны – это был шаг в неизведанное. Всегда проще опереться на что-то знакомое.
Перевод - качественный. Переводчик не просто механически перевёл текст с одного языка на другой, но и позаботился о том, чтобы смысл на русском языке был выражен так же чётко, как и на английском.
Три главных кита DDD - единый язык, модель предметной области и углубляющий рефакторинг.
1. Единый язык
Если абстрагироваться от технических деталей, то ключевая концепция книги - «единый язык», на котором должны говорить и писать все участники проекта – как специалисты в предметной области (например, представители заказчика), так и разработчики.
Действительно, сегментация языков и двойной (а то и тройной перевод) служат причиной огромного числа недопониманий и ошибок: бизнес-пользователь что-то сказал ИТ-специалисту на стороне заказчика, тот перевёл на свой язык и донес это до системного аналитика подрядчика, тот в свою очередь перевёл и донёс до разработчиков. На каждом этапе качество и точность информации снижается. Единый язык позволяет создать единое коммуникационное пространство и кардинально повысить качество коммуникаций.
При условии, разумеется, что участники проекта готовы учиться и хотят понимать друг друга.
2. Модель предметной области
Единый язык выражается в модели предметной области. Модель в книге обычно представляется в виде UML-диаграмм – как правило, используются диаграммы классов.
В приложении должен быть "слой (или уровень) предметной области", явно и недвусмысленно выражающий модель. Код данного слоя должен быть написан максимально понятно; Эванс даже предполагается что его можно показывать специалистам в предметной области, и они способны его понять с минимальными комментариями.
К слову, некоторые русские адепты DDD считают что раз мы общаемся с заказчиком и на русском языке, то и код должен быть на русском. Компиляторы большинства языков позволяют присваивают русскоязычные идентификаторы.
Слой предметной области – это ядро приложения, реализующее функциональность, за которую пользователи платят деньги. У автора временами проскальзывает какой-то супремасизм – что разработчики которые пишут «слой предметной области» это элита, всё остальное второстепенно и не так важно для успеха приложения.
3. Углубляющий рефакторинг
Помимо технического рефакторинга, улучшающего код, автор активно продвигает рефакторинг модели. Если в процессе обсуждения с пользователями модели предметной области на едином языке все участники приходят к выводу что текущая модель не совсем адекватно отражает понятия реального мира и может быть улучшена, то это нужно сделать. При этом рефакторинг должен найти отражение и в едином языке, и в модели, и в коде. Такой рефакторинг автор называет «углубляющим», имея в виду что он углубляет понимание и точность модели.
Автор считает, что в процессе постоянного «углубляющего рефакторинга» можно выйти на очень простую и точную модель, которая упростит дальнейшее развитие приложения - что окупит все расходы на его проведение.
Супер-разработчики
Необычна вера автора в то, что разработчики могут одинаково успешно общаться со специалистами в предметной области и писать код. Эванс даже приводит пример разработчика, который специально пошел в книжный магазин и купил книгу по основам бухучета, чтобы лучше понимать пользователей. Я аналитиков-то не всегда могу на это сподвигнуть...
При этом судя по контексту «разработчик» в книге – это именно разработчик (т.к. программист), а не «член команды разработки». То есть человек, непосредственным результатом работы которого является программный код.
Такие универсалы действительно бывают, но не часто. Известных мне специалистов, успешных в обеих ипостасях, можно пересчитать по пальцам двух рук. Как правило, есть явный перекос в ту или иную сторону – либо код кривоват, либо понимание предметной области поверхностное.
В этом мнении автор не одинок, такие же супер-разработчики встречаются и у Каннингема, и у Бека, и у Фаулера. Интересно, действительно на западе был этап развития ИТ, когда такие эксперты были мейнстримом? Или автор просто ограничивается собственным опытом?
Другие роли в книге упоминаются мельком, например про «аналитиков» сказано всего один раз. Было бы интересно узнать, как сохранять «единый язык» в команде, где есть разные роли.
Архитектура
Еще интересно употребление термина «архитектура». Понятие «архитектура» в российском ИТ-сообществе чаще всего применяется именно к «технической архитектуре» - какую СУБД выбрать, как горизонтально масштабировать решение, как достигнуть «четырёх девяток». Учитывая, что для простых приложений «техническая архитектура» является вырожденной, бытует мнение что «архитекторы не нужны кроме сложных случаев».
В книге же понятие «архитектура» в первую очередь относится к построению модели предметной области – какие сущности мы выделяем, какими обязанностями их наделяем, где проводим границы агрегатов и так далее.
В этом есть смысл – зачастую построение модели предметной области происходит где-то на стыке между разработчиками и системными аналитиками, и этой задаче не уделяется должного внимания. А неверно подобранные абстракции могут очень сильно усложнить жизнь.
Актуальность книги
Книга написана в 2004 году, и её техническая часть несовременна: примеры основаны на функциональных возможностях Java 1.4. Это было до бума сервисно-ориентированной и тем более микросервисной архитектуры, до широкого проникновения функциональной парадигмы в языки программирования общего назначения, до широкого распространения асинхронного обмена сообщениями, даже до появления обобщенных типов в Java.
Было бы крайне интересно увидеть второе издание «синей книги»», учитывающее текущий уровень развития ИТ – именно от Эванса. Последующие мне книги по DDD от других авторов более конкретны и не дотягивают по уровню концептуальности до «синей книги».
Концептуальная часть книги по-прежнему актуальна, ничего принципиально нового в системном анализа не появилось.
