CommandはHTTP Requestではなく状態変更の意図を表す
Commandは、Applicationに対して「何をしたいか」という状態変更の意図を明示するmessage/objectとして使える。例えば ArchiveProject、ApproveInvoice、PublishRelease のように、単なるfield updateではなく業務上のtaskを名前にする。
MicrosoftのCQRS patternでは、Commandをdata-centricな低水準更新ではなく、specific business taskを表すものとして説明している。SetStatus=Booked より BookHotelRoom の方が意図を表しやすい、という考え方である。一方、Bertrand Meyer由来のCommand Query Separationを説明するMartin Fowlerの記事では、Commandはstateを変更しvalueを返さず、Queryはvalueを返してstateを変更しない、というより厳密な区別を置く。実際のApplication FrameworkではCommand handlerが作成IDや結果を返すこともあり、用語の厳密さには流派差がある。
OperationはTransportから独立したApplication Capabilityとして置ける との違いは、Operationを「Applicationが提供するCapability」と見るのに対し、Commandはそのうち主にstate-changing capabilityへの具体的な呼び出し表現として置ける点にある。
Operation: ArchiveProject というCapability
Command: ArchiveProject{ProjectID, Reason} という要求
HTTP adapterがrequest bodyからCommandを組み立ててもよいし、MCP ToolやJob messageから同じCommandを作ってもよい。ただし、Transport非依存なtyped function callだけで十分ならCommand objectを別に作る必然性はない。
Commandを導入する価値が出やすいのは、validation、idempotency、audit、retry、queueingなど「要求そのもの」を一級のdataとして扱いたい場合である。逆に単純なCRUDまで必ずCommand classへ包むと型とfileが増え、Localization CostはLayerと抽象化を増やすほど無視できなくなる を上げる。
CommandはCommand BusはOperation dispatchの選択肢でありArchitectureの前提ではない やCQRSはRead ModelとWrite Modelの分離でありCommand BusやEvent Sourcingの同義語ではない の前提として語られやすいが、Commandを使うこととBusを使うこと、CQRSを採用することは別の判断である。