Хорошо ли вернуть модель домена из REST api в приложение DDD?

Ответ 1

Как правило, вы хотите иметь возможность изменять объекты домена (например, когда вы узнаете что-то новое о домене), не изменяя публичный интерфейс /API для вашей системы. То же самое и наоборот: если для публичного интерфейса требуется изменение, вы не хотите менять свою модель домена.

Таким образом, с этой точки зрения я никогда бы не раскрывал свои объекты домена как есть через открытый интерфейс. Вместо этого я бы создал объекты передачи данных (DTO), которые являются частью открытого интерфейса. Таким образом, изменения в моем домене и public api могут меняться независимо.

Ответ 2

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

Я хотел бы добавить ответ, потому что упоминание интерфейса CRUD заставляет меня думать, что это может быть случай злоупотребления SOA, когда принципы SOA используются для склеивания слоев приложения, а не из сети приложений. SOA понимается как способ для предприятия передавать свои системы, это не способ реализации MVC! Так просто, но так неправильно понято. Например, только потому, что ваш внешний интерфейс GUI использует службы для доступа к серверу, у вас нет приложения "SOA".... что это значит.

Если это относится к SOA, используемому для склеивания слоев, пожалуйста, пересмотрите свой дизайн и используйте соответствующую архитектуру дизайна для этого уровня абстракции. В противном случае вы неверно истолковываете приведенные здесь рекомендации о том, чтобы не подвергать DDD-модели, а не использовать CRUDY, и вы наверняка закончите создание отдельной модели домена для интерфейса служб, и тогда вам придется сопоставлять DDD, что так сложно что вам нужно будет использовать бульдозер и тому подобное, чтобы сопоставить одно и то же с разными именами и т.д., пока мы не закончим раздутый бесполезный беспорядок...

.. просто будьте осторожны.

для -Alex-

Редзеди настолько прав, что нам нужно разъяснение....

Как и все, это гораздо сложнее, чем сказать. Сериализация сложной модели домена может быть настолько сложной, что вы можете либо не вставлять какую-либо логику в домен, а антивирусную модель анемии (http://martinfowler.com/bliki/AnemicDomainModel.html) или иметь отдельную анемическую модель для постоянство, то есть DTO.

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

В моем опыте использования модели домена в течение многих лет, я считаю, что лучшее, что является точкой в ​​середине. Да, как утверждает Фаулер и Эванс, бизнес-объекты должны нести логику, но не все (http://codebetter.com/gregyoung/2009/07/15/the-anemic-domain-model-pattern/) небольшую анемию с хороший сервисный уровень лучше всего.

Например, счет-фактура должен знать о своих товарах и иметь процедуру для расчета его общей суммы, которая зависит от позиций. Но элемент счета не должен знать о выставлении счетов. Итак, что происходит, когда элемент изменяется в стоимости, должен ли он иметь указатель обратно на счет-фактуру отца в качестве циркулярной справки и вызывать подсчет всей суммы счета?

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

для -Alex-