ソフトウェア工学 command-message

2

2つのエンタープライズ統合パターンは、コマンドメッセージとイベントメッセージです。私は、他のシステムとの統合だけでなく、サービス間の内部通信にもメッセージングを使用するシステムに取り組んでいます。ことになって最終的に一貫性のあるシステム、およびサービスは、（カップル専用のサービスへの例外を除いて）お互いの無知ことになっています。そのため、リモートプロシージャコール（RPCまたはRPI）のように感じることは避けようとします。バスとメッセージ指向のミドルウェアシステムがあり、すべてのメッセージがブロードキャストされます。私たちは、過去完了でフレーズとして、あるイベント、例えば、として私たちのメッセージに名前を付ける傾向がありますPurchaseOrderShipped。ただし、多くの場合、イベントは他のサービスがイベントについて知る必要がある場合にのみ追加され、最初は多くの場合1つのサービスのみが重要です。さらに、そのサービスは結果としてイベントを発行することがあり、そのイベントは最初のサービスでリッスンされます。したがって、相互作用を図にすると、イベントメッセージの図よりも上のリンクのコマンドメッセージの図（またはRPC図）のように見えますが、これは実際には実装されていませんダイレクトメッセージングですが、バスでブロードキャストします。それに加えて、コマンドとして名前が付けられたいくつかのメッセージが追加されたことを最近見たという事実、つまり、命令のフレーズ、例えばBillShippedPurchaseOrder。奇妙なことに、メッセージの名前とその流れは、イベントとして命名されたかコマンドとして命名されたかによって変わりません。では、何かがコマンドメッセージかイベントかをどのように判断するのでしょうか？これはセマンティクスと命名の単なる違いですか、それともコマンドとイベントメッセージの実際の実装の違いはありますか？すべてのメッセージがブロードキャストされていることを考えると、それらのどれもが本当にコマンドメッセージではないということですか？

11 enterprise-architecture messaging event command-message

3

CQRS / ESでは、コマンドは別のコマンドを作成できますか？

CQRS / ESでは、コマンドはクライアントからサーバーに送信され、適切なコマンドハンドラーにルーティングされます。そのコマンドハンドラーは、リポジトリーからアグリゲートをロードし、その上のいくつかのメソッドを呼び出して、それをリポジトリーに保存します。イベントが生成されます。イベントハンドラー/佐賀/プロセスマネージャーは、コマンドを発行するためにこれらのイベントをリッスンできます。そのため、コマンド（入力）はイベント（出力）を生成し、それがシステムにさらにコマンド（入力）をフィードバックできます。さて、コマンドがイベントを発行せず、別のコマンドをエンキューするのが一般的な方法でしょうか？このようなアプローチは、外部プロセスでの実行を強制するために使用できます。編集：私が考えている特定のユースケースは、支払いの詳細の処理です。クライアントはPayInvoiceコマンドを送信します。そのペイロードにはユーザーのクレジットカードの詳細が含まれます。PayInvoiceHandler通過MakeInvoicePayment支払いゲートウェイとの相互作用の原因である別のプロセスにコマンドを。支払いが成功すると、InvoicePaidイベントが生成されます。PayInvoiceコマンドが保持された後、コマンドが保持される前に何らかの理由でシステムがクラッシュした場合MakeInvoicePaymentは、これを手動で追跡できます（支払いは行われません）。MakeInvoicePaymentコマンドが持続した後、システムがクラッシュする前にInvoicePaidイベントが持続する場合、ユーザーのクレジットカードに請求が行われているのに、請求書に支払い済みのフラグが付けられていない可能性があります。その場合、状況を手動で調査し、請求書に手動で支払い済みのマークを付ける必要があります。

10 domain-driven-design cqrs event-sourcing command-message

2

「その他」の集合体の状態をどこで検証する必要がありますか？

シナリオ：顧客が注文し、製品を受け取った後、注文プロセスに関するフィードバックを提供します。次の集計ルートを想定します。お客様注文フィードバックビジネスルールは次のとおりです。顧客は自分の注文についてのみフィードバックを提供でき、他の人のフィードバックは提供できません。顧客は、注文に対する支払いが済んでいる場合にのみフィードバックを提供できます。 class Feedback { public function __construct($feedbackId, Customer $customer, Order $order, $content) { if ($customer->customerId() != $order->customerId()) { // Error } if (!$order->isPaid()) { // Error } $this->feedbackId = $feedbackId; $this->customerId = $customerId; $this->orderId = $orderId; $this->content = $content; } } ここで、企業が新しいルールを望んでいると想定します。 …

8 domain-driven-design validation cqrs command-message onion-architecture

タグ付けされた質問 「command-message」

タグ付けされた質問「command-message」