Comments 28
Идеи в книге правильные, но как это все там описано - полнейший буллшит. Никому не могу порекомендовать ее читать, что бы разобраться c DDD есть более достойные книги/источники без лишней воды и двусмыслицы.
Посоветуете конкретные?
Вот. Более понятно написана. Некоторые даже советуют начинать DDD с неё, а уже потом к синей книжке Еванса переходить.
А вы сделайте скидку на то, что эта книга была издана ещё в 2004м году! Эта книга и её идеи лежат в основе современного ДДД.
Пожалуйста, посоветуйте без воды и двусмыслия. Без шуток, очень нужно, я за последний месяц перечитал уйму информации по DDD и мне все больше кажется, что это больше религия с своими апосталами и трактовками.
Нескромно конечно, но советую: https://habr.com/ru/company/jugru/blog/503868/
Вам не кажется, оно так и есть на самом деле :)
Вы не один в этом ощущении, поверьте :)
Это и есть религия с апостолоами и трактовками. Я бы даже сказал "ересь от ООП", которая сильно усложняет жизнь сегодня ради сомнительного профита в загробной жизни (которой, как известно, нет).
Мне наиболее вразумительной показалась "красная" книжка, Vaughn Vernon — Implementing Domain Driven Design.
Если пробьётесь через ужасный перевод (читал оглядываясь на оригинал, иначе никак) и критически посмострите на примеры кода — вы лишний раз убедитесь в своём ощущении
Сомнительность профита зависит от ваших задач. Фактически делать по DDD или не делать по DDD - это компромисс между читаемостью кода и устойчивостью к нарушениям инвариантов VS сложностью написания кода и производительностью. @vkhorikovлучше всех сформулировал: https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/, https://khorikov.org/posts/2020-08-14-domain-modeling-trillema-examples/.
Простите, но проблемы подобные DDD трилеме возникают только у тех, кто практикует DDD. То есть вначале создается произвольный набор правил, который якобы должен помогать, а потом оказывается, что у вас проблемы, так как код не соответствует вашим придуманным правилам.
Как мне кажется, главная проблема все этих Driven-Development практик в том, что их создают и пропагандируют всякие консультанты, которые живут в мире стрелочек, диаграмок и детских примеров в стиле "как добавить метод для смены email к классу User". И к реальному программированию каких-либо крупных проектов имеют очень мало отношения.
Вы можете указать на кого-то конкретного? Я больше видел консультантов по agile очень плохо представляющих о чем они говорят, а не по driven-development. Допускаю, что необразованных хватает везде:)
Вон Вернон, Реализация методов предметно-ориентированного проектирования. Лучше в оригинале "Implementing Domain Driven Design". Он как раз писал эту книгу во многом с целью раскрыть то что написал Эванс
Выберите книгу, и с командой поэтапно пробуйте что-либо: спецификации, агрегаты, CQS, иммутабельные типы и т.д. Ошибкой будет пытаться сделать всё сразу, особенно в одиночку.
Сначала я читал Эванса. Читаю, что-то воды много, думаю, ну может это такое введение долгое. Читаю дальше, то же самое. Перелистываю на другие главы, и там все в таком же духе. Ну ладно, думаю, почитаю Вернона, там же все-таки о реализации книга. Читаю, и там такая же история. В итоге, прочитал сокращенный вариант - "Domain Driven Design Quickly". Там на ста страницах все рассказано, и даже довольно развернуто, как мне показалось.
В общем, по моим впечатлениям, это книги для разработчиков с низкой квалификацией или малоопытных, чтобы они хоть как-то могли писать код. "Чистый код" и "Чистая архитектура" Роберта Мартина, видимо, им сложно понять.
Ага, ну т.е. оригинал читать не будем. Почитаем изложение… основной косяк там с тем что тактические паттерны идут до стратегического дизайна. В остальном книга Эванса - это источник, на который опираются остальные.
Почитал комментарии к книге, после ее покупки, и подумал, ну не! Данную книгу, я когда-то давно уже начинал читать, но в тот момент книга мне показалась сложной и запутанной. Вот я решил вернуться к ней через года, зачем ?, не знаю, просто что б почитать. Начну с того, что автор постоянно ссылается на какие-то примеры кода, не до конца раскрывая их суть. Т.е. иногда уловить мысль, очень сложно, затем если ты садишься думать, как так получилось что, тот код, который автор собрался рефакторить, родился на свет, ты остаешься в полном недоумении, как такой код вообще мог появиться. Опять же, возможно это из-за того, что автор, говоря нам о том, что как важно следовать модели бизнеса не раскрывает задачу до конца, ну и самый треш, когда он начинает ссылаться на код, рассмотренный в книгах Фаулера, и других ребят (список литературы в конце книге), т.е. такое чувство, что если ты хочешь разобраться (ну прям вникнуть), нужно сперва прочесть вот тот список, и возможно тогда, ты будешь на одной волне с автором. В общем я не могу сказать, что это книга стоит уделенного ей внимания и потраченных денег. По мне книги Мэтт Зандстра, Мартина Фаулера, принесут в ваш багаж знаний, гораздо больше чем данная книга.
У Мартина Фаулера книга прекрасная, но она не имеет отношения к ddd.
Автор книги, ссылается на книги Фаулера, а так у Фаулера очень много разных публикаций, например: https://martinfowler.com/tags/domain driven design.html
Предметно-ориентированное проектирование (DDD) | Эванс Эрик — обзор книги и рекомендации