Я совершенно новый с DDD и хотел бы узнать о любых ловушках, которые вы, возможно, захотите поделиться. Я обобщу его позже, чтобы узнать больше новичков:)
Спасибо
Резюме:
Есть хорошая презентация по этой теме, а также здесь (видео).
Вероятно, самый важный: не громить центральный, фундаментальный принцип модели домена и его представление на языке Ubiquitous. Благодаря множеству вариантов технологий, очень легко для вашей головы заполнить ORM, MVC-фреймворки, ajax, sql vs nosql,... Таким образом, осталось немного места для реальной проблемы, которую вы пытаетесь решить.
И это сообщение с ключом DDD: нет. Вместо этого в первую очередь сосредоточьтесь на проблемном пространстве. Постройте модель домена, лишенную архитектурного беспорядка, которая захватывает, раскрывает и передает домен.
О, и еще один: думая, что вам нужны Domain Services для всего, что вы можете сделать в модели домена. Нет. Вы всегда должны сначала попытаться поместить логику домена с типом Entity/Value, к которому она принадлежит. Вы должны создавать службы домена только при поиске функций, которые, естественно, не относятся к E/V. В противном случае вы попадете в модель анемичного домена, выделенную в другом месте.
НТН.
Одна из самых больших проблем заключается в том, что вы в конечном итоге получаете так называемую анемическую модель, где ваши сущности в основном относятся только к данным и не содержат бизнес-логики. Эта ситуация часто возникает, когда вы строите свою модель домена поверх существующей реляционной модели данных и просто делаете каждую таблицу в базе данных сущностью в своей модели домена.
Вы можете наслаждаться презентацией Грега Янга о том, почему DDD терпит неудачу.
Короче:
Не использовать ограниченные контексты. Это к задней части большой синей книги, но Эрик Эванс записал, что считает, что ограниченные контексты и вездесущий язык являются наиболее важными понятиями.
Аналогично, люди склонны слишком сильно фокусироваться на шаблонах. Это не мясо DDD.
Кроме того, если у вас нет большого доступа к экспертам домена, вы, вероятно, не будете делать DDD, в лучшем случае вы DDDish.
Более конкретно, если вы закончите с отношениями "многие ко многим", вы, вероятно, разработали что-то неправильно и вам нужно переоценить свои совокупные корни/контексты.
Это не из моего личного опыта с предметом, но он несколько раз упоминался в книгах DDD, и это то, о чем я думал недавно: использовать объекты, когда вам действительно нужна личность, в других случаях используйте Объект значения. I.e., шаблон Entity часто оказывается выбором по умолчанию для любого существительного модели, и это не так, как должно быть.
Остерегайтесь Big Ball of Mud.
Одна из ловушек архитектуры, основанной на домене, заключается в том, чтобы ввести двусмысленность в модель. Как поясняется в статье Стратегический бизнес-дизайн с привязкой к контексту:
Неоднозначность - супер-злодей нашей Вездесущий язык
Это может произойти, когда два разных понятия имеют одно и то же имя или когда одна и та же концепция может иметь разные виды использования. Может потребоваться
выставить структуру домена в условия ограниченного контекста в контексте карта
Если модель используется слишком многими различными способами или имеет слишком много обязанностей, это может быть признаком того, что ее нужно разделить.
Только добавление к тому, что уже сказали другие; Мой личный опыт заключается в том, что люди часто получают анемичную модель и единую модель вместо нескольких контекстно-зависимых моделей.
Другая проблема заключается в том, что многие больше сосредотачиваются на инфраструктуре и шаблонах, используемых в DDD. Просто потому, что у вас есть сущности и репозитории и используются (n) Hubernate, это не значит, что вы делаете DDD.