CQRSとイベントソーシングを使用した倉庫管理システム。 要件のステートメント

最近、 オムニチャネルのコンセプトは、顧客サービスの品質を改善するために、さまざまな販売チャネルが1つに統合されたときに一般的になりました。 そして、販売がどのように、どこで行われたとしても、売り手がすべての販売チャネルを組み合わせて注文を履行することは理にかなっています。 実際には、これは、クライアントがオフラインで来て、モバイルアプリケーションまたは電話モードでサイトで注文を行っても、利用可能なすべての手段を使用して完了する必要があることを意味します。 そして、売り手としてのあなたにとって、個々のチャネルは大きな違いであってはなりません。 フランクフルト空港の例に関するオムニチャネルのプレゼンテーション （英語）。

上記を統合するには、売り手が在庫レベルを統合できることが非常に重要です。 小売インフラストラクチャは非常に複雑であり、外部倉庫、店舗、店舗に商品を注文する可能性がある店舗（ 集荷 ）、 ドロップシッピング （サプライヤー企業の製品を販売する取引スキームであり、それ自体が購入者に送信するため）あなたの名前、そしてあなたはバイヤーからお金を受け取るだけです）。




特定のビジネス向けのターンキー統合を備えた特定のソリューションではなく、フレームワークを開発しているため、私たちの一連の要件は非常に広いことが判明しました。
主な要件は次のとおりです。

• 在庫管理システムは、注文時のチェックアウト中にボトルネックになってはいけません。 つまり 各倉庫での製品の可用性と、それらに伴う潜在的な閉塞の関連性について、同期チェックを行うべきではありません。
• システムは非同期注文処理をサポートする必要があります。この場合、注文自体の作成はシステムの状態を変更する操作ではありません。 そして、チームは登録されるだけで、後で処理する必要があります。 したがって、注文を出すというタイムクリティカルな操作は、ロックなしで非常に迅速に行われます。 このような実装は、たとえばAmazonで見ることができます。注文と支払いが正常に行われた後、買い手は倉庫に十分な商品がなく、お金を返すため、システムが注文を完了できないことを通知する手紙を時間内に受け取る場合があります。 一方で、これは顧客のエクスペリエンスを悪化させる可能性がありますが、1日あたり何十万もの販売を行う大規模な倉庫を持つ売り手にとって、注文のプロセスをスピードアップするためにこのリスクは正当化されます。
• システムは、複数の倉庫からエンドユーザーに商品を配送するためのさまざまなアルゴリズムを提供する必要があります。 たとえば、最も単純なケースでは、各配送元が優先順位によって示される優先配送であり、システムはこの優先順位に従って各倉庫からの注文を満たすために最大の商品を取得しようとします。 より基本的なアルゴリズムには、クライアントとセラーの最小送料（最小送料）を個別に決定することが含まれます。
• 在庫管理システムは、バイヤーのフロントエンドで、現在のコンテキスト内の特定の製品の特定の集約フローの値を提供する必要があります。 また、この値は、商品を販売するとき、または在庫切れかどうかを評価するときに考慮されます。 これは、特に製品カテゴリの古いページなどの重要なページで実行時に各製品の在庫をカウントしないために必要です。これには十分な時間がかかり、生産性が低下する可能性があります。
• システムは、売り手が販売を予約できる場合、たとえば、時間通りに完了する必要がある卸売り顧客のために、予約メカニズムをサポートする必要があります。 その後、予約製品を他の販売チャネルを介して他の顧客に販売することはできません。
• システムは、倉庫の混雑やその他の商品の物理的な場所を監視するためのメカニズムを提供する必要があります。 在庫を補充する必要がある場合に、物流と商品の配送を計画および編成できるようにする。
• 前の段落をサポートするには、そのような問題を解決するために、製品の特別な条件も導入する必要があります：商品はそれぞれ販売されていますが、まだ倉庫から出荷されておらず、倉庫内の場所を占有しているため、この倉庫に新しい商品をインポートすることはできません。 また、買い手によって返品された商品は、必ずしもすぐに在庫に返されるとは限りません。 製品が誤動作または欠陥のために返品される場合があり、そのような製品は個別に処理する必要があります。
• ドロップシッピングのサポート
• システムは、物理的な倉庫を販売チャネルにマッピングする柔軟な機能を提供する必要があります。 この商品については別途

物理的な倉庫と保管庫の販売チャネルへのマッピング

この図は、製品が販売チャネルにある物理倉庫のさまざまなマッピングオプションを示しています。 販売チャネルとは、商品を市場に配送する方法と、その後の販売を意味します。 たとえば、Magentoの観点では、これはWebサイトでもかまいませんが、B2Bの登場により、別の販売チャネルが卸売クライアントになり、個別の割引があり、個別に取引できます。 この場合、販売チャネルは顧客グループになります。 また、販売チャネルの良い例は、国または地域です。

この図からわかるように、物理的な倉庫は仮想集約に結合され、特定の販売チャネルに順番に割り当てられます。 同時に、1つの物理的な倉庫が複数の販売チャネルに対応でき、複数の倉庫からの在庫を販売チャネル内で組み合わせることができます。 これにより、最大限の柔軟性を実現し、必要に応じて新しい販売チャネルを導入し、既存の在庫をそれらに一致させることができます。

Magento MSI（マルチソースインベントリ）

この記事は、「CQRSとイベントソーシングを使用した倉庫管理システム」シリーズの最初の記事で、Magento 2の例を使用した倉庫管理システムの要件の収集、設計、開発について検討します。

開発が進行中であり、コミュニティエンジニアが関与し、プロジェクトの現在のステータスとドキュメントに精通できるオープンプロジェクトは、 github.com / magento-engcom / magento2 / projectsで入手できます。