Ловушки доменного дизайна (DDD)

Ответ 1

Вероятно, самый важный: не громить центральный, фундаментальный принцип модели домена и его представление на языке Ubiquitous. Благодаря множеству вариантов технологий, очень легко для вашей головы заполнить ORM, MVC-фреймворки, ajax, sql vs nosql,... Таким образом, осталось немного места для реальной проблемы, которую вы пытаетесь решить.

И это сообщение с ключом DDD: нет. Вместо этого в первую очередь сосредоточьтесь на проблемном пространстве. Постройте модель домена, лишенную архитектурного беспорядка, которая захватывает, раскрывает и передает домен.

О, и еще один: думая, что вам нужны Domain Services для всего, что вы можете сделать в модели домена. Нет. Вы всегда должны сначала попытаться поместить логику домена с типом Entity/Value, к которому она принадлежит. Вы должны создавать службы домена только при поиске функций, которые, естественно, не относятся к E/V. В противном случае вы попадете в модель анемичного домена, выделенную в другом месте.

НТН.

Ответ 2

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

Ответ 3

Вы можете наслаждаться презентацией Грега Янга о том, почему DDD терпит неудачу.

Короче:

• Отсутствие намерения
• Модель анемичного домена.
• DDD-Lite
• Отсутствие изоляции
• Вездесущий, что?
• Отсутствие уточнения
• Прокси-сервер (бизнес-аналитик)

Ответ 4

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

Аналогично, люди склонны слишком сильно фокусироваться на шаблонах. Это не мясо DDD.

Кроме того, если у вас нет большого доступа к экспертам домена, вы, вероятно, не будете делать DDD, в лучшем случае вы DDDish.

Более конкретно, если вы закончите с отношениями "многие ко многим", вы, вероятно, разработали что-то неправильно и вам нужно переоценить свои совокупные корни/контексты.

Ответ 5

Это не из моего личного опыта с предметом, но он несколько раз упоминался в книгах DDD, и это то, о чем я думал недавно: использовать объекты, когда вам действительно нужна личность, в других случаях используйте Объект значения. I.e., шаблон Entity часто оказывается выбором по умолчанию для любого существительного модели, и это не так, как должно быть.

Ответ 6

Остерегайтесь Big Ball of Mud.

Одна из ловушек архитектуры, основанной на домене, заключается в том, чтобы ввести двусмысленность в модель. Как поясняется в статье Стратегический бизнес-дизайн с привязкой к контексту:

Неоднозначность - супер-злодей нашей Вездесущий язык

Это может произойти, когда два разных понятия имеют одно и то же имя или когда одна и та же концепция может иметь разные виды использования. Может потребоваться

выставить структуру домена в условия ограниченного контекста в контексте карта

Если модель используется слишком многими различными способами или имеет слишком много обязанностей, это может быть признаком того, что ее нужно разделить.

Ответ 7

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

Другая проблема заключается в том, что многие больше сосредотачиваются на инфраструктуре и шаблонах, используемых в DDD. Просто потому, что у вас есть сущности и репозитории и используются (n) Hubernate, это не значит, что вы делаете DDD.