Подводные камни (DDD) подводные камни

Question

Я совсем новичок в DDD и хотел бы знать о любых подводных камнях, которыми вы можете поделиться.Я подведу итоги позже, чтобы узнать больше новичков:)

Спасибо

Резюме на данный момент:

• Модель анемичного домена , где ваши объектыв основном только данные и не содержат бизнес-логики
• Недостаточно ограниченные контексты
• Слишком много внимания уделяется шаблонам

Хорошая презентация по этой темехорошо здесь (видео).

Answer 1

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

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

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

НТН.

Answer 2

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

Answer 3

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

Короче говоря:

• Отсутствие намерений
• Анемичный доменМодель
• DDD-Lite
• Отсутствие изоляции
• Вездесущий что?
• Отсутствие уточнения
• Proxy Domain Expert (бизнес-аналитик)

Answer 4

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

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

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

Если говорить более конкретно, если вы столкнетесь с отношениями "многие ко многим", вы, вероятно, разработали что-то неправильное и вам необходимо пересмотреть ваши совокупные корни / контексты

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

может потребоваться представить доменную структуру в терминах ограниченного контекста в контекстной карте

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