Владимир Хориков — Domain-driven design: Cамое важное

что такое рефорт для рефакторинга??

У меня возник вопрос
Будет ли богатая доменная модель прототипом так называемого God object, реализация которого не является хорошей практикой?

Можно уточнить с момент - Должны быть Рич модели, которые знают сами что можно делать с ними, но они не должны знать как себя сохранить? То есть, рич на пол-шишечки?!

Wow!Killlin!!!

Спасибо коллегам из мира java для windows 😊

В пет проекте так и делал, пользуясь С и О принципами солид, не догадываясь про ДДД. Оказывается ДДД расширяет эти принципы. Очень похоже про те штуки, за которые топил Егор Бугаенко. Единственное не согласен, что надо лепить все в один класс. Я бы выделил емеил и статус в отдельную бизнес сущность, и создал класс ответственный за эту сущность и пусть он ее меняет.

Книгу записал в todo.

Очень емко, точно, мне все стало понятно, спасибо!

Вот сомневаюсь - например вычисление процентов по кредиту -там 100500 интеграций. Вот не место им сущности Заемщик

если бы я не знал аглийский то ничего бы непонял. на пример, Сущность ето Entity? @Vladimir should you publish this to Pluralsight as another DDD course? Something like "DDD in one hour"?

Очень хороший доклад!

Жаль, что pluralsight закрыт для России. Хотел там подписаться на курсы автора

для чего синхронизировать поля модели из одного контекста в другой, а потом ещё постоянно контролировать какие из них можно только читать, если можно просто хранить ID на модель из другого контекста, и всё выше перечисленное можно будет избежать

Владимир отличный пример привел! Спасибо за доклад!

Спасибо за доклад! Поддержу предыдущих комментаторов - отличная подача и разъяснения, очень помогли!

ЗЫ. Единственное замечание: было бы хорошо поменьше использовать англицизмы при докладах на русском языке, но я понимаю, что когда практики английского больше, чем русского, это может происходить невольно (читай "на-автомате").

Владимир, Вы потрясающий докладчик! Давно не слушал настолько крутого доклада!

Отличный доклад - редко когда видно, что человек понимает о чем говорит, а значит и может донести мысль до слушателя

не вижу проблемы передать в модель репозиторий через интерфейсную ссылку. Да, это говорит о том, что это где то храниться, но где и как - не открывает. Можно хранить по факту хоть в блокноте

Пример по моему подобран удачно.
Сразу становится понятно про разделение контекста в случае схожих сущностей (Customer и Product)
Спасибо за доклад

Хм...
Программирование - точная наука. Но, сам процесс - творческий.
Любой паттерн - превращает искусство программиста в ширпотреб для масс.
Это НЕ плохо, но и не надо безоговорочно следовать правилам. Следовать надо контексту задачи и окружения.
Тот же customer в 99% случаев принадлежит "третьей стороне" (каталогу пользователей). И, смысл городить цепочку вызовов "потому, что так в паттерне" вместо прямого обращения к каталогу на проверку дублей e-mail? Да и алгоритмы посика/сравнения в службе наверняка поинтереснее (оптимальнее) самописных.
Всё больше убеждаюсь, что со времен изобретения ООП, SOA, витрин данных, "наросла" масса модных трактовок/методик суть которых - Думай прежде чем что-то написать и помни о тех, кто будет править код после тебя.

Не думал, что рекомендуется заводить 2 разные сущности кастомера физически.

Классный доклад!

шикарный доклад и огромное спасибо Владимиру за талант понятно доносить материал

Черт. Нельзя еще раз лайкнуть...

Книга по тестированию супер! рекомендую всем, must read

Такой вопрос, разбили на контексты и написали приложение. Через год понимаем что помимо Продаж и Поддержка нужен еще контекст Маркетинг(или любой другой), как быть в такой ситуации? Насколько деление на контексты является гибким решением? А бывает так что "добавьте вот такую маленькую фичу", фича и правда маленькая но не ложится в существующие контексты, а создавать новый может быть дорого для бизнеса.

Спасибо за доклад. В примере с изменением почтового адреса можно соблюсти изоляцию, инкапсуляцию и быстродействие: ChangeEmail(Email email, List<Users> usersWithEmail) а в контролере выбрать не всех пользователей а только тех что имеют такую же почту, оверхед - 1 запрос к БД, но запрос все равно должен быть, лист будет либо пустым либо содержать одного пользователя. Понятно, что не всегда можно провернуть такой фокус.

Пока лучшее что я видел по DDD для чайников (коим и являюсь).
33 минута, по этой логике и Name нужно обернуть в класс ведь можно указать и пробел или символ и т.п. Важно найти баланс но с другой стороны обернуть в класс не сложно оставив различные валидации и усовершенствования класса своим потомкам)))

👍

Супер! Отличный доклад, спасибо.

Вот те раз , всегда боролись и пропагандировали за анемичную модель , из-за ее слабой связанности и гибкости в плане расширения возможных операций над ней , и тут на тебе , снова в 90-е ) . У богатой модели много проблем , это паутина , в которой с ростом модели не разобраться , ее тяжело масштабировать , а при внезапно новом бизнес правиле многое переписывать.

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

Очень холиварный вопрос, тестить без интерфейсов будет так себе. Засунуть всё в модель не очень хорошая идея. Возможно хотя бы сделать модель и интерфейс действий, потом это всё унаследовать в конечную сервис-модель, но опять же это не общепринято.
Но искать логику по моделям размазанную, идея не очень хорошая. Триллема бы не появилась, если бы работали отдельно.
К тому же CQRS или сам подход разделения чтения и записи сомнителен в озвученном подходе, и прелестно ложится на интерфейсный.
Всё таки хорошо, когда есть домен, есть действия домена и объединение это в сущность домена, которая может действия.

Владимир не очень честно поступает, показывая полную модель с передачей репозитория в агрегат =) В такой реализации модель выглядит "грязнее", чем модель без асинхронного поведения. Репозиторий это прикладной сервис и ему нечего делать в доменной модели

Честнее было бы передавать доменный сервис как интерфейс IUniqueEmailCheck

Изолированную модель тестировать, безусловно, проще, но ИМХО расползание логики контроля инвариантов в долгой перспективе бьет куда больнее, нежели нарушение изоляции.

Пример с адресом электронной почты - это особый случай, когда нужна валидация не в рамках одного аггрегата, а множества аггрегатов. Там в полный рост встают вопросы о транзакционных границах, серилазиуемости операций и прочая головная боль. Но если отвлечься от этого нюанса, то я б еще рассмотрел подход с ValueObject'ом, имеющим тип UniqueEmail и передачей оного в метод Customer.ChangeEmail. А вот служба, которая конвертирует строку в UniqueEmail, пусть проверяет все, что требуется. Но это уже больше в стиле книги Domain Modeling Made Functional.

Супер спасибо