Денис Цветцих. Чистая Архитектура и DDD 10 лет спустя

Вот по поводу оверхеда valueObject, в примере нет самоинкапсуляции, которая гарантирует корректность типа, соответственно бизнес логики над заведомо корректной моделью тоже нет в примере. На моей практике тудо перетикает почти половина бизнеслогики проекта и отлично тестируется. Для домашнего проекта это перебор, но когда у вас 3 года на проект и 20 пронраммистов, это должно быть.

Реклама курса на юдеми из доклада заинтересовала но качество звука отбило все желание изучать такой курс, даже если контент неплохой

Про каскадное удаление, это не в базе потому что бизнес правило.

насчет тысяч и тысяч ValueObjects недопонимание, самих объектов-то может быть много, но классов/типов из которых они конструируются мало. здесь достигается переиспользование кода, различные Entity могут собиратся из однотипных объектов-значений.

Интересно, но не согласен

В финале странноватый наезд на абстрактного архитектора за «вкусовщину». Кажется, что как раз вкусовщиной является безосновательное неприятие некоторых описанных практик, так как в описанном новом проекте а) лектор не в курсе решаемых задач б) нет ещё никаких проблем. Но раз архитектор не лектор, а другой человек, то это его зона ответственности и такая «голая» критика выбора техник есть не критика техник, а критика специалиста их выбравшего, что вообще уже попахивает личной неприязнью.

dislike

какой-то бредогенератор. чего хочет сказать сам не знает

По докладу видно несколько раз, что автор очень невнимательно читал книгу Вон Вернона.
1. Слой портов не означает, что порт должен быть один, например только для БД. В той же книге пример системы, где через них интегрируются несколько сервисов.
2. Он совсем не понял зачем нужны агрегаты - это границы транзакционной консистентности объектов. Поэтому они не должны быть слишком маленькими, но и не слишком большими (будут проблемы с производительностью, но никакого профита).
3. Насчёт вколачивания ORM в модель - этого не надо делать, т.к. логику работы модели нужно оставить максимально простую. Там и без ORM будет много сложностей. В добавок, модели могут уходить в разные порты через Anticorruption Layer.
4. Никто не говорит, что DDD нужно всегда затаскивать в проект. DDD - это инструмент для проектов со сложной богатой бизнес логикой. Автор походу с ними просто не сталкивался, а решил похайпить, что типа использует DDD и всё про него понял. Чтобы такие проекты поддерживать в адекватном состоянии нужно выставить соответствующие рамки, а не делать как привыкли для CRUD админок.

Ну и вообще автор - такой же консультант с платными курсами, как и те люди, которых он в корысти обвиняет. Помолчал бы лучше, чем гнать на просветителей, которые имеют опыта побольше автора, пусть сейчас и "на пенсии" и лучше бы шел внимательнее читать книги.