CQRS - Должна ли команда попытаться создать «сложную» сущность master-detail?

Question

Я читал мысли Грега Янга и Уди Дахана о командообразовании Ответственное разделение, и многое из того, что я читаю, вызывает у меня аккорд. Мой домен (мы отслеживаем транспортные средства, которые делают поставки) имеет концепцию маршрута, который содержит один или несколько остановок. Мне нужно, чтобы мои клиенты могли установить их в нашей системе, позвонив в веб-сервис, а затем сможет получить информацию о маршруте и о том, как продвигается транспортное средство.

В прошлом у меня были бы «вырезанные» классы DTO, которые очень похожи на мои классы домена, и клиент создавал RouteDto с массивом StopDto (s) и вызывал наш веб-метод CreateRoute, передавая в RouteDto , Когда они запрашивают нашу систему, вызывая метод GetRouteDetails, я бы возвращал им те же самые объекты. Одним из привлекательных аспектов CQRS является то, что RouteDto может иметь всевозможные свойства, которые клиент хочет запросить, но не имеет деловых параметров при создании маршрута. Поэтому я создаю отдельный класс CreateRouteRequest, который передается при вызове команды CreateRoute, и класс DTO маршрута, который возвращается как результат запроса.

class Route{ 
    string Reference; 
    List<Stop> Stops; 
} 

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

Дайте моему классу CreateRouteRequest свойство Stops (s), которое представляет собой массив «что-то», представляющее данные, необходимые для каждой остановки, но что я называю этим классом ? Это не Stop, так как я называю список DTO внутри своего маршрута DTO, но мне не нравится «CreateStopRequest». Я также задаюсь вопросом, не застрял ли я в мышлении CRUD, думая в терминах информации о мастер-деталях и прося, чтобы клиент тоже так думал.

class CreateRouteRequest{ 
    string Reference; 
    ... 
    List<CreateStopRequest> Stops; 
} 

или

Они называют CreateRoute, а затем сделать несколько звонков метода AddStopToRoute. Это кажется немного более «поведенческим», но я потеряю способность обрабатывать создание маршрута, включая его остановки, как одну атомную команду. Если они создают маршрут и затем пытаются добавить Stop, который не удается из-за некоторой проблемы проверки, у них будет частично правильный маршрут.

Тот факт, что я не могу найти хорошее имя для списка объектов «StopCreationData», с которыми я буду работать в варианте 1, заставляет задуматься, есть ли что-то, что мне не хватает.

Answer 1

Я не думаю, что вам что-то не хватает.

class CreateRouteRequest{ 
    string Reference; 
    ... 
    List<CreateStopRequest> Stops; 
} 

Выглядит хорошо. Альтернатива использования AddStopToRoute - это, на мой взгляд, не очень хорошая идея, так как она создает слишком «чатный» интерфейс для эффективного использования удаленно.

Answer 2

Однако использование вами запроса CreateRoute * * указывает, что вы используете шаблон Request/Response.

Если вы действительно отправляете команды на сервер, сервер не должен возвращать объект/сообщение Response. Вы можете просто предоставить вашему сервису метод ExecuteCommand и вызвать его, передав CreateRouteCommand.

Запрос/Ответ не является правильным CQRS IMHO.

Answer 3

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

Наконечник используется в качестве «создания» в качестве глагола. «Создайте», я нашел, это то же самое, что «вставить» в уме разработчика (подумайте «CRUD»), и мы часто прибегаем к этому глаголу, когда мы впервые начинаем пробуждать DDD, потому что он кажется менее техническим. Однако маршруты, созданные «здесь», уже существуют. Они просто записываются в систему. В то же время остановки на маршруте уже существуют, но также записываются. Простое изменение восприятия и формулировки, возможно, с помощью RecordRouteCommand с дополнительной сопутствующей коллекцией RecordStopOnRouteCommand, возможно, немного устранило путаницу. Возможность отправки команд остановки записи независимо друг от друга обеспечивала бы большую гибкость при построении и укреплении API.

Я также согласен с Szymon о запросе против команды. Эта формулировка также приводит к мысли, противоречащей подходу cqrs. Если есть одна вещь, которую меня научил DDD, то слова, которые мы используем в наших проектах, не просто важны, они имеют первостепенное значение.