イベント駆動型システムの設計における効果的な方法論
イベント駆動型システムの「仕組み」を理解し、シンプルなシステムを構築しました。しかし、効率的に設計するのに少し苦労していることがわかりました。
たとえば、すべてのイベントを事前に定式化するのは簡単ではないようです。後で最初に決定した一部のイベントを削除または名前を変更していることに気づきました。
もう1つは、これらのイベントを事前に気にする必要があるサービスを決定することです。例：「orderPrepared」イベント？ Ahhサービスx、y、zはそれを必要とします。私のドリフトをキャッチ？
私の質問は、ビジネス要件を決定した後、イベント駆動型システムを設計する際の方法論は何でしょうか？実際にどのように効果的に「すべてレイアウト」し、後で変更を最小限に抑えるのですか？
私は Big Design Up Front の擁護者ではありませんが、NoDesign Up Frontの擁護者でもありません。一部のシステムは十分に複雑であり、それらを十分に検討する必要があります。複数のシステムが連携して動作し、それらを接続するイベント（またはメッセージ）がある場合、多くの場合、ミスの影響を受ける複数のチームがあります。
アジャイル方法論には ジャストインタイムデザイン の概念があります。基本的に、実際に機能を実装する必要がある直前まで設計を延期します。スプリントでの動作は次のようになります。
リリーストレイン：
- スプリント1： スパイク を実行して相互作用を設計する
- スプリント2：タスクを分解して実装を開始する
- スプリント3：実装の完了、統合テストの実行、バグレポートの作成
- スプリント4：ファイナライズ、回帰テスト、およびデプロイ
その後、すすぎ、その後、各リリーストレインについて繰り返します。
アイディアは、あなたのスパイクがタイムボックス化されており、あなたはじっくりと考え抜いたことです：
- システムを統合するために必要なイベント/メッセージ
- イベント/メッセージに含める必要がある情報
- 必要な保証または対応（ある場合）
スパイクの最後に、誰でも参照できるように記述し、詳細を実装する必要がある場合はバックログにタスクを作成して、それらのタスクを処理できるようにします。
BDUPがそうであることが知られているようなマニューシャに入らないため、これはうまく機能します。また、設計成果物は、チーム全体で役立つように適切な抽象化レベルで構築されます。設計に必要な情報の種類は常に変更される可能性がありますが、それらの変更は、時間の経過に伴う微調整を伴う単純な反復である必要があります。
@Robert Harveyがコメントで述べたように、事前にすべてを知る方法はありません。また、システムを設計する前に要件に自信がある場合でも、要件が変更されないと想定すると、後で悪夢が訪れることになります。
あなたは拡張可能なデザインを探しているので、それをさらに分解すると役立つでしょう。
1。一部のイベントの名前変更/削除。これを修正する方法？大声で考えて、どのイベントを読み取る必要があるかを決定するためにサービスがフェッチできる構成はどうでしょうか。これは頻繁に変更されることが予想されるので、これを、イベントのフェッチと配信だけを処理することを目的とした本当に軽量なサービスにしてみてください。これにより、イベントの変更を終了する場合、構成を変更する必要がある場合があり、サービスが構成をプル/リフレッシュすると、新しいイベントが読み取られます。
2。これらのイベントを事前に気にするはずのサービスを特定する。 pub-subモデルはこれに役立ちませんか？パブリッシャーは、イベントの送信先を実際に知る必要はありません。それをシンクにダンプし、任意の数のサービスが任意の数のイベントをサブスクライブできます。
イベント駆動型システムを設計する際の方法論は何ですか？
1。分離：サービスを、変更が他のサービスにカスケードされないと思われるレベルに分類します。問題が発生した場合は、サービスだけで失敗するようにします。
2。構成を自由に使用してください。構成は作業システムの調整パラメーターとして機能し、変更可能なすべてのものを構成に移動します。
3。イベントの読み取りのコンテキストでリスナーが多くの重労働を行わないようにしてください。
4。システムをべき等にし、必要に応じてログを検討し、失敗時に再試行し、必要に応じてイベントを再生します。良いガイド こちら
古臭く聞こえるかもしれませんが、イベント駆動型システムをモデル化する最も確実な方法は、状態遷移図（別名ステートマシン）を使用することです。 UMLに慣れていない場合は、イベントリストを使用してモデリングを行うことができます。ホワイトボードでそれを行うことができ、非常に簡略化された例を次に示します。 （大文字の名詞は、実際の実装で必要になるクラスへの最初の近似です。）
ユーザーが書籍のコピーをリクエストする[このイベントは、開始点から最初の状態への移行をトリガーします：コピーがリクエストされました]
ライブラリアンはLibrarySysSessionで、ブックのコピーが利用可能かどうかをチェックします[これは、コピーが要求された状態内のアクションです]
コピーが利用できない場合
LibrarySysSessionは「コピー不可」を表示します[このアクションは状態マシンのエンドポイントへの遷移をトリガーします]
コピーが利用可能な場合
LibrarySysは「コピー可能」を表示します[このアクションは「コピー可能」状態への移行をトリガーします]
司書はコピーを予約します[このアクションはコピー予約状態への移行をトリガーします]
ライブラリアンは物理コピーをフェッチします[これはコピー予約状態での最初のアクションです]
ライブラリアンはコピーのリースを登録します[このアクションはコピーのリース状態への移行をトリガーします]
司書がコピーをユーザーに手渡します[これはコピーリース状態での最初のアクションです]
など...もちろん、ソフトウェアエンジニアリングツールを使用して、ステートマシン図を描画するのが最適です。ただし、イベントリストは、特に非常に俊敏な環境で、最も経済的な方法です。 Doチームメンバーに、ホワイトボードリストをGoogleドキュメント、OfficeLibre、または使用しているものにコピーしてもらいます。
ちなみに、イベントリストは、オブジェクト指向の分析と設計でクラスを識別するために使用された最初の方法の1つでした。
ご多幸を祈る！
ドメインドリブンデザインの森にどのくらい深く入りたいかに応じて、 Event Storming を検討できます。
これらのいずれかを実行すると、関心のあるドメインイベントなどが強調表示され、それらがシステムの残りの部分とどのように関連するかがわかります。ドメインイベントは、イベントソースのイベントと同じではないことに注意してください。しかし、それらを理解することで、「必要なイベント」の問題を解決するのに役立ちます。ドメインイベントは、システムの概念ではなくビジネスアクションです。
ウィキペディアの記事はかなり良い要約ですが、ワークショップ後の要約を読むことはそれを感じ取る良い方法です。 Open Practice Library には、優れたリソースのリストがあります。
ドメインイベントをより明確に把握していれば、必要なシステムイベント/コンポーネントに対する必然的な変更がはるかに簡単になることがわかりました。
Event Streams in Action を読むことをお勧めします。