域驱动设计 – CQRS – 命令是否应该尝试创建“复杂”的主 – 细

我一直在阅读Greg Young和Udi Dahan关于Command Query Responsibilty Separation的想法,我读到的很多内容都与我产生了共鸣.我的域名(我们跟踪正在交付的车辆)具有包含一个或多个停靠点的路线概念.我需要我的客户能够通过调用Web服务在我们的系统中设置它们,然后能够检索有关路线的信息以及车辆的进展情况.

在过去,我会“删减”与我的域类非常相似的DTO类,客户会创建一个带有StopDto数组的RouteDto,并调用我们的CreateRoute web方法,传递RouteDto.当他们通过调用GetRouteDetails方法查询我们的系统时,我会向它们返回完全相同的对象. CQRS的一个吸引人的方面是RouteDto可能具有客户想要查询的所有属性,但在创建Route时没有业务设置.所以我创建了一个单独的CreateRouteRequest类,它在调用CreateRoute“命令”时传入,而一个Route DTO类作为查询结果返回.

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

但是我需要我的客户在创建路线时为我提供路线和停止详细信息.我看到它可以……

给我的CreateRouteRequest类一个Stops(s)属性,这是一个“某事”数组,表示他们需要提供的关于每个停止的数据 – 但是我该怎么称呼这个类？这不是一个Stop,因为我在Route DTO中调用了DTO列表,但我不喜欢“CreateStopRequest”.我也想知道我是否陷入了一种CRUD心态,在这里思考主要细节信息并要求客户也这样思考.

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

要么

他们调用CreateRoute,然后对AddStopToRoute方法进行多次调用.这感觉更“行为”,但我将失去处理创建路线的能力,包括其作为单个原子命令的停止.如果他们创建了一个Route然后尝试添加一个由于某些验证问题而失败的Stop,那么他们将会有一个部分正确的Route.

事实上,我不能为我在选项1中使用的“StopCreationData”对象列表提供一个好名字,这让我想知道是否有我遗漏的东西.