イベントドリブンアーキテクチャに取り掛かり、コマンドとイベントの命名規則が何であるかを知りたいと思います。私はこれを多く知っています：イベントはフォームSomethingHappenedにする必要がありますコマンドはDoSomethingのフォームにする必要があります。明確にする必要があるのは、コマンドに「コマンド」を、イベントに「イベント」を追加する必要がある場合です。 DoSomethingCommandとは対照的に、DoSomethingとSomethingHappenedEventはSomethingHappenedとは対照的です。私はまた、その理念がコミュニティ優先コンベンションの背景にあるのか知りたいと思う。ありがとう！コマンドとイベントの命名規則
CommandおよびEventの接尾辞はオプションであり、優先事項です。私はそれらを省略して、名前だけからその意図を明白にすることを好む。コマンドとイベントに名前を付ける最も重要な点は、技術ドメインよりもビジネスドメインを反映していることを確認することです。 Create、Update、Add、Changeのような多くの用語は、あまりにも技術的であり、ビジネスドメインではあまり意味がありません。たとえば、UpdateCustomerAddressというのではなく、より大きなビジネスコンテキストを持つRelocateCustomerと言うことができます。
ありがとう、私はこのアプローチを使用して実装を開始しました。私は@MikaelÖstbergのネームスペースの使い方の点も好きです。イベント/コマンドを追加すると、オブジェクトをインスタンス化する際の読み込みが良くなっているように見えましたが、私が気付いたのはちょっとしたことです。比較： 'VARのuserSignedOut =新しいUserSignedOut（）{};' ' bus.Publish（userSignedOut）;' ' bus.Publish（userSignedOutEvent）;' を 'VARのuserSignedOutEvent =新しいUserSignedOutEvent（）{}を有します。 ' – Tolu
私の慣習は名前空間に依存し、それは私が接尾辞イベントもコマンドも使用しないことを意味します。
また、コマンドとイベントは、影響を受ける集約タイプに基づいて別々の名前空間に編成されます。
例：
// Commands
MyApp.Messages.Commands.Customers.Create
MyApp.Messages.Commands.Orders.Create
MyApp.Messages.Commands.Orders.AddProduct
// Events
MyApp.Messages.Events.Customers.Created
MyApp.Messages.Events.Orders.Created
MyApp.Messages.Events.Orders.ProductAdded
要件に応じて、あなたが別のアセンブリにあなたのイベントを配置することをお勧めします。この理由は、ダウンストリームシステムにイベントを配布する必要がある場合に発生します。その場合、おそらくダウンストリームシステムがあなたのコマンドについて気にする必要がないように（そうしてはならないので）、あなたはおそらく望んでいません。
ありがとう、@ミカエル。これは多くの意味を持ち、私が現在傾いている方向です。標準的なプラクティスが何であるかを明確にしたかっただけです。 – Tolu
私はこれが標準的な習慣であるとは言いません。これは私のやり方です。しかし、これは、ネームスペースをフルネームの一部として使用し、サフィックスやものであなた自身を繰り返さないネットの規則に従うと思います。唯一の欠点は、「作成済み」という20のイベントのうちの1つにusingステートメントを追加したいときに、resharperがたくさんのオプションを提供することです。 –
私はコマンドとイベントを別々のアセンブリに分けて、前述の@MikaelÖstbergとは異なる名前空間を使う傾向があります。私は、これらのメッセージの最後にコマンドやイベントをタックすることを推奨しません。 +1 –
yorコマンド/イベントの名前が正しく指定されている場合、コマンドとイベントの追加は冗長な情報になります。これはあなたのコードを読みにくくするノイズになります。ハンガリー記法を覚えていますか？私が知っているほとんどのプログラマーはもうそれを使用しません。
コマンドとイベントは、アプリケーション用に言語 ... APIを構成します。 「コマンド」や「イベント」のような用語の使用は、エンジニアリング用語がエンティティの目的に意味をなされるシステムレベルの定義にはおそらく役に立ちますが、ドメインの動作の定義を扱う場合は、システム/技術用語を削除し、ビジネススピークに賛成する。あなたのコードをより自然に読んで、タイピングを減らします。 私は 'Command'/'Event'付属品から始めましたが、それは時間の無駄であり、普及したユビキタス言語DDDから私を引き離したことに気付きました。 HTH、 マイク
は、私は多くのことを見て自分自身を使用してきた大会は、イベントが過去形にすると何が起こったのか説明しなければならないことである。
コマンドはあなたがしたいことです。そうすることを示す名前を作成します。組織のよう
を、私は通常、彼らがためのものであることを根骨材と一緒にそれらを置きます。あなたができることとどのような出来事が起こったのかを見るのがずっと簡単です。
つまり、私は各ルート集合体の名前空間を作成し、その下にすべてを置く（リポジトリ定義、イベント、コマンド）。
など
ありがとう！ちょうどそうした。方法を理解するために少し時間がかかりました。 – Tolu