Доменное моделирование, доменные объекты в DDD

Question

Я действительно новичок в DDD и пытаюсь понять некоторые концепции.

Может кто-нибудь объяснить мне идею моделирования домена в DDD.

Я уже прошел объяснение в Википедии: http://en.wikipedia.org/wiki/Domain_model, но все еще кажется, что в моем понимании есть серые области.

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

Разве это не то, что было на практике всегда? в объектно-ориентированном мире вы моделируете бизнес-объекты на классы, объекты и т. д. и создаете программное обеспечение на основе этого.

Чего я не понимаю, так это того, что моделирование доменов уделяется DDD. Это то же самое моделирование объекта / класса, которое вы найдете в мире ОО, или это что-то новое для DDD? Чем он отличается от объектно-ориентированного дизайна / моделирования?

Ваши ответы высоко ценятся.

Answer 1

Одно из отличий состоит в том, что "правильная" реализация модели доменной модели в DDD изолирована от сквозных проблем.

Например, он не имеет ничего общего с базами данных или другим постоянством. Там, где он содержит логику проверки, это проверка бизнеса, а не «имя превышает длину столбца?» проверка.

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

С другой стороны, «программное обеспечение» относится к IO, UI и т. П., Но делегирует всю бизнес-логику модели предметной области.

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

Answer 2

Домен в DDD не нужно реализовывать в OO. По моему опыту модель OO-доменов, как правило, лучше всего, но есть очень веские примеры ситуаций, в которых она может отсутствовать.

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