Command Query Responsibilty Separation に関する Greg Young と Udi Dahan の考えを読んでいて、読んだ内容の多くが心に響きました。私のドメイン (配達を行っている車両を追跡しています) には、1 つ以上のストップを含むルートの概念があります。顧客が Web サービスを呼び出してシステムでこれらを設定できるようにし、ルートと車両の進行状況に関する情報を取得できるようにする必要があります。
以前は、ドメイン クラスに非常によく似た「カットダウン」DTO クラスがあり、顧客は StopDto の配列を使用して RouteDto を作成し、CreateRoute Web メソッドを呼び出して RouteDto を渡していました。彼らが GetRouteDetails メソッドを呼び出してシステムにクエリを実行すると、まったく同じオブジェクトが返されます。CQRS の魅力的な側面の 1 つは、RouteDto には、顧客が照会したいあらゆる種類のプロパティが含まれる可能性があるが、Route を作成するときにビジネス設定がないことです。そのため、CreateRoute「コマンド」を呼び出すときに渡される CreateRouteRequest クラスと、クエリ結果として返される Route DTO クラスを個別に作成します。
class Route{
string Reference;
List<Stop> Stops;
}
しかし、顧客がルートを作成するときに、ルートとストップの詳細を提供してもらう必要があります。私が見たとき、私はどちらかをすることができました...
CreateRouteRequest クラスに、各停留所について提供する必要があるデータを表す「何か」の配列である Stops(s) プロパティを指定しますが、このクラスを何と呼ぶのでしょうか? Route DTO 内の DTO のリストと呼んでいるので、これは Stop ではありませんが、「CreateStopRequest」は好きではありません。また、ここで CRUD の考え方にとらわれていて、マスター/詳細情報の観点から考え、顧客にもそのように考えるよう求めているのではないかと思います。
class CreateRouteRequest{
string Reference;
...
List<CreateStopRequest> Stops;
}
また
CreateRoute を呼び出してから、AddStopToRoute メソッドを何度も呼び出します。これはもう少し「行動的」に感じますが、ストップを含むルートの作成を単一のアトミック コマンドとして扱う能力を失うことになります。ルートを作成してからストップを追加しようとすると、検証の問題が原因で失敗し、部分的に正しいルートになります。
オプション 1 で使用する "StopCreationData" オブジェクトのリストに適切な名前を付けられないという事実は、何かが欠けているのではないかと考えさせられます。