CQRS - Команда должна попытаться создать “сложный” объект основной детали?

Я читал Greg Young и мысли Udi Dahan о Запросе Команды Разделение Responsibilty и многое из того, что я считал, вызывает отклик во мне. Мой домен (мы отслеживаем механизмы, которые делают, доставки) имеет понятие Маршрута, который содержит одну или несколько Остановок. Мне нужны мои клиенты, чтобы смочь настроить их в нашей системе путем вызова веб-сервиса и затем смочь получить информацию о Маршруте и как механизм прогрессирует.

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

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

Но мне нужен мой клиент для предоставления мне детали Маршрута И Остановки, когда они создают маршрут. Поскольку я вижу его, я мог также...

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

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

или

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

То, что я не могу придумать хорошее название списка объектов "StopCreationData", с которыми я работал бы в опции 1, заставляет меня задаться вопросом, существует ли что-то, что я пропускаю.