как избежать анемичной модели предметной области? - PullRequest
1 голос
/ 02 ноября 2011

Я пытаюсь выучить Domain Driven Design на примере, и мне нужен ваш совет.Допустим, у меня есть сущность под названием Тендер.Я получаю Мыльное Сообщение от внешней службы;в сообщении содержится вся информация о тендере (tenderId, tenderSum, ...)

Что мне нужно сделать:

  1. Получить сообщение с помощью веб-службы Soap и поместить его вочередь сообщений - выполняется Сервисом
  2. Получить сообщение из очереди - выполняется Сервисом
  3. Перейти в базу данных, получить объект Tenderпо tenderId или создайте новый тендер - сделанный репозиторий
  4. Заполните поля объекта Tender значениями из сообщения - сделанный Доменный объект Тендер
  5. Сохранение тендера в базе данных - сделано Репозитарий

Я попытался сделать это правильно, но в итоге я обнаружил, что большая часть кода живет вУслуги, Репозитории и т. Д. Я действительно запутался.Что я сделал не так?Должен ли я делать все эти вещи внутри объекта домена?

Ответы [ 3 ]

3 голосов
/ 02 ноября 2011

Нередко некоторые сущности / объекты значений в DDD имеют очень небольшое поведение.Я почти уверен, что в любом проекте у вас будет хотя бы несколько сущностей / ВО, которые имеют лишь некоторую логику построения и будут неизменными.Это не главная проблема DDD.

Вместо этого вы должны сосредоточиться на выявлении и (пере) определении ваших ограниченных контекстов и агрегатов.В Интернете вы найдете много информации об этом ( dddcommunity - хорошее началоМолодой.

2 голосов
/ 02 ноября 2011

Я обнаружил, что часто то, что начинается с того, что все живущее в услугах, со временем меняется по мере развития модели.В вашем примере одним из вариантов может быть назначение члена метода вашей сущности с именем Tender.LoadValuesFrom[ServiceName](val1, val1, etc) (если имя службы имеет значение в домене).

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

1 голос
/ 02 ноября 2011

Думаю, вы не одиноки с такими мыслями. Что обычно заканчивается в моей модели, так это валидация, управление агрегатами, и я также стараюсь сосредоточиться на объектах значений. Постарайтесь свести к минимуму свойства авто, приглашайте к быстрой разработке, не задумываясь ... Я написал статью в своем блоге об этом некоторое время назад ... http://magnusbackeus.wordpress.com/2011/05/31/preventing-anemic-domain-model-where-is-my-model-behaviour/

Но это итеративная работа, поиск подходящей модели. Будьте готовы сделать много рефакторинга ...

...