flowing retail
1.0.0
このサンプル アプリケーションは、複数の独立したコンポーネント (マイクロサービスなど) に分解された単純な注文フルフィルメント システムを示しています。
リポジトリには、幅広いユーザーがコードを理解し、代替案を比較できるようにするために、複数の実装代替案のコードが含まれています。以下の表に、これらの代替手段を示します。
この例は、ドメイン駆動設計 (DDD) 、イベント駆動アーキテクチャ (EDA)、マイクロサービス (μS)から学んだことを尊重しており、これらのトピックに実際にアクセスできるように設計されています。
注:このコードは説明のために書かれたものです。したがって、私は一般的なソリューションを使用した実稼働対応のコードよりも、簡略化されたコードまたはコピー アンド ペーストを好みました。コーディング スタイルのベスト プラクティスを考慮しないでください。これは、簡単に説明できるコードになるように意図的に書かれています。
概念の詳細については、O'Reilly の『Practical Process Automation』ブックを参照してください。
Flowing Retail は、非常に簡単な注文フルフィルメント システムをシミュレートします。
最も基本的な選択は、通信メカニズムを選択することです。
通信メカニズムの次の選択肢はワークフロー エンジンです。
そしてプログラミング言語:
Flowing Retail は、非常に簡単な注文履行システムをシミュレートします。ビジネス ロジックは、上に示したサービスに分割されています (コンテキスト マップとして示されています)。
一部のサービスは本質的に長時間実行されます。たとえば、支払いサービスでは、有効期限が切れたクレジット カードを更新するよう顧客に求められます。ワークフロー エンジンは、これらの長時間実行される対話を永続化し、制御するために使用されます。
ステート マシン (この場合はワークフロー エンジン) は 1 つのサービス内で使用されるライブラリであることに注意してください。さまざまなサービスがワークフロー エンジンを必要とする場合、必要なエンジンを実行できます。このように、フレームワークを使用するかどうか、およびどのフレームワークを使用するかは、自律的なチームの決定になります。
