Пример DDD: CargoRepository.Store () может быть использован в контроллере? - PullRequest
Новая
       35

Пример DDD: CargoRepository.Store () может быть использован в контроллере?

1 голос
/ 07 марта 2011

Я ищу отличный источник NDDDSample из http://code.google.com/p/ndddsample, чтобы узнать о DDD. Путаюсь с чем-то

В CargoRepository есть метод Find (), который вызывается BookingService.AssignCargoToRoute () и CargoTrackingController.Search (): 

Cargo cargo = CargoRepository.Find(trackingId);

CargoRepository также имеет метод Store (), вызываемый из BookingService.AssignCargoToRoute (): 

Cargo cargo = cargoRepository.Find(trackingId);
if (cargo == null)
{
    throw new ArgumentException("Can't assign itinerary to non-existing cargo " + trackingId);
}

cargo.AssignToRoute(itinerary);
cargoRepository.Store(cargo);

Моя путаница заключается в том, что, похоже, ничто не мешает CargoTrackingController вызывать CargoRepository.Store (), который обходит бизнес-логику в BookingService.AssignCargoToRoute ()

Почему это разрешено в DDD? Следует ли разделить репозиторий на два: один для чтения для приложения / ui / domain / service и один для записи для домена / services?

Ответы [ 3 ]

2 голосов
/ 07 марта 2011

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

В вашем примере кажется, что Cargo.AssignToRoute (маршрут) и BookingService.AssignCargoToRoute () являются избыточными.Наличие этих двух способов привязки груза к маршруту создает путаницу.Вы можете оставить любой из них, в зависимости от того, считаете ли вы, что Cargo несет ответственность за назначение себе маршрута, или от того, что он перегружает объект функциональностью, которой он не принадлежит.

Кроме этогодля контроллера вполне законно вызывать метод Repository напрямую.Сервисы не являются единой точкой доступа для контроллеров.

1 голос
/ 07 марта 2011

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

Не среда, которая ограничивает вас (разработчика) от неправильного использования, DDD - это шаблон проектирования (руководство по организации структуры вашего приложения).

1 голос
/ 07 марта 2011

Ну, я думаю, это то, чего пытается достичь CQRS.

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

...