CQRSとイベントソーシングを使用した倉庫管理システム。 サービス層

この記事では、Magento 2のサービスレイヤーと、エンティティを管理するためのサービス（API）について説明します。これらは、倉庫管理システム（インベントリ）のドメインエンティティの設計と割り当てに関する以前の記事で説明しました。

サービス層

Magento 2プラットフォームで倉庫管理システムを記述しているため、それに応じて、このプラットフォームの機能を考慮して、紹介するサービスについて説明します。

Magento 2では、モジュールレベル（バウンドコンテキスト内）で弱い接続の原則を実装するために、サービスレイヤーが導入されました。これは、クライアントと他のシステムモジュールの相互作用に関して各モジュールで利用可能な操作のセットを定義します。



Magentoのサービスレイヤー（またはサービスコントラクト）は 、モジュールに対して定義され、このモジュールのApiフォルダーにあるPHPインターフェイスのセットです。 サービスコントラクトは、データインターフェース-ドメインエンティティデータを表すDTOインターフェースで構成されています。 およびサービスインターフェイス-クライアント（コントローラー、REST / SOAP Webサービス、他のモジュールのPHPコード）から呼び出すことができるビジネスロジックへのアクセスを提供するインターフェイス。



モジュールのすべての外部クライアントは、サービス層で記述された契約の下で動作すると想定されているため、サービス層は実際にはFacadeとして表すことができ、実装の詳細とビジネスロジックの複雑さを隠します。

お客様は、明確に定義されたAPIに依存することで、モジュールがセマンティックバージョニングに従うため、システムの次のバージョンへのアップグレードが容易になります。



モジュール性と分離を改善するために、サービスコントラクトがサービスから別のモジュールに割り当てられる場合があります。 たとえば、Inventoryの場合、2つのモジュールがあります。1つはInventoryAPIサービスインターフェイスのセットを宣言し、2つ目はこれらのインターフェイスの実装を提供します-Inventoryです。 したがって、基本実装を置き換えたいサードパーティの開発者は、コード内でこの実装に縛られなくなります。 システム内の他のモジュールが依存するインターフェイスであるため、彼が必要とするのはインターフェイスだけです。

リポジトリインターフェイス-リポジトリ

リポジトリは、エンティティに一連のCRUD操作を提供するインターフェイスです。

典型的なリポジトリインターフェイスは、次のメソッドのセットで構成されています。

public function save(\Magento\Module\Api\Data\DataInterface $entityData); public function get($entityId); public function delete(\Magento\Module\Api\Data\DataInterface $entityData); public function deleteById($entityId); public function getList(SearchCriteriaInterface $searchCriteria);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドのセットは、定義済みのセットとは異なるセマンティクスを持つメソッドを追加することは推奨されないため、より狭い場合があります（特定の操作がドメインエンティティに一般的でない場合。削除など）。 このような方法は、別のサービスに配置することをお勧めします。



リポジトリは、エンティティを管理するための一連のメソッドを組み合わせたファサードと考えることができます。



Inventoryモジュールのコンテキストでは、 Sourceエンティティ（製品がある物理的な倉庫を表す責任を負うエンティティ）およびSourceItem （エンティティバンドル、特定の物理ストレージ上の特定の製品（SKU）の量を表す）のリポジトリが表示されます。

 /** * This is Facade for basic operations with Source * There is no delete method, as Source can't be deleted from the system because we want to keep Order information for all orders placed. Sources can be disabled instead. * * Used fully qualified namespaces in annotations for proper work of WebApi request parser * * @api */ interface SourceRepositoryInterface { /** * Save Source data * * @param \Magento\InventoryApi\Api\Data\SourceInterface $source * @return int * @throws \Magento\Framework\Exception\CouldNotSaveException */ public function save(SourceInterface $source); /** * Get Source data by given sourceId. If you want to create plugin on get method, also you need to create separate * plugin on getList method, because entity loading way is different for these methods * * @param int $sourceId * @return \Magento\InventoryApi\Api\Data\SourceInterface * @throws \Magento\Framework\Exception\NoSuchEntityException */ public function get($sourceId); /** * Load Source data collection by given search criteria * * @param \Magento\Framework\Api\SearchCriteriaInterface $searchCriteria * @return \Magento\InventoryApi\Api\Data\SourceSearchResultsInterface */ public function getList(SearchCriteriaInterface $searchCriteria = null); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

SourceRepositoryの場合、deleteメソッドはありません。Sourceエンティティに対するビジネスオペレーションは存在しないためです。なぜなら、発注された注文（商品の配送元を含む）に関連するすべての情報を常に保存する必要があるからです。 したがって、将来的にそのようなデータが失われる可能性を防ぐ必要があります（配信が実行されたソースを削除することにより）。 代わりに、操作が使用されます-ソースを非アクティブ（無効）としてマークします。

 /** * This is Facade for basic operations with SourceItem * * The method save is absent, due to different semantic (save multiple) * @see SourceItemSaveInterface * * There is no get method because SourceItem identifies by compound identifier (sku and source_id), * thus, it's needed to use getList() method * * Used fully qualified namespaces in annotations for proper work of WebApi request parser * * @api */ interface SourceItemRepositoryInterface { /** * Load Source Item data collection by given search criteria * * We need to have this method for direct work with Source Items, as Source Item contains * additional data like qty, status (can be searchable by additional field) * * @param \Magento\Framework\Api\SearchCriteriaInterface $searchCriteria * @return \Magento\InventoryApi\Api\Data\SourceItemSearchResultsInterface */ public function getList(SearchCriteriaInterface $searchCriteria); /** * Delete Source Item data * * @param SourceItemInterface $sourceItem * @return void * @throws \Magento\Framework\Exception\NoSuchEntityException * @throws \Magento\Framework\Exception\CouldNotDeleteException */ public function delete(SourceItemInterface $sourceItem); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

保存操作を使用するための主なシナリオは、リポジトリ内の標準的な保存規約が想定しているように、1つのエンティティではなくSourceItemのセットで発生するためです。

シンクのインポートまたは外部ERPまたはPIMシステムとの同期中に発生する可能性のある複数の保存については、個別のSourceItemSaveInterfaceコントラクトが導入され、単一のサービスコール内で複数のSourceItemをアトミックに保存する機能を提供します。 このようなコントラクトにより、データベースへの単一のクエリを使用して挿入操作を処理でき、処理が大幅に高速化されます。 単一のエンティティを使用する基本的な保存操作は、実際にはこの場合サードパーティの開発者が両方の保存操作（単一および複数）をプラグインする必要があるため、リポジトリコントラクトに追加されません。 したがって、1つの拡張ポイントのカスタマイズが常に望ましいようです。



複数の保存コマンドコントラクトは、 Magento \ InventoryApi \ Api \ SourceItemSaveInterfaceのようになります

 /** * Service method for source items save multiple * Performance efficient API, used for stock synchronization * * Used fully qualified namespaces in annotations for proper work of WebApi request parser * * @api */ interface SourceItemSaveInterface { /** * Save Multiple Source item data * * @param \Magento\InventoryApi\Api\Data\SourceItemInterface[] $sourceItems * @return void * @throws \Magento\Framework\Exception\InputException * @throws \Magento\Framework\Exception\CouldNotSaveException */ public function execute(array $sourceItems); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その実装であるSourceItemSaveは、 SaveMultipleモデルリソースの保存を委任します。



また、SourceItemはリンクされたエンティティであり、複合識別子（SKUとSourceId）によって決定されるため、SourceItemRepositoryにはget（）メソッドはありません。



Stock（ソースエンティティの仮想集約）のリポジトリは標準に見えます：

 interface StockRepositoryInterface { /** * Save Stock data * * @param \Magento\InventoryApi\Api\Data\StockInterface $stock * @return int * @throws \Magento\Framework\Exception\CouldNotSaveException */ public function save(StockInterface $stock); /** * Get Stock data by given stockId. If you want to create plugin on get method, also you need to create separate * plugin on getList method, because entity loading way is different for these methods * * @param int $stockId * @return \Magento\InventoryApi\Api\Data\StockInterface * @throws \Magento\Framework\Exception\NoSuchEntityException */ public function get($stockId); /** * Find Stocks by given SearchCriteria * * @param \Magento\Framework\Api\SearchCriteriaInterface|null $searchCriteria * @return \Magento\InventoryApi\Api\Data\StockSearchResultsInterface */ public function getList(SearchCriteriaInterface $searchCriteria = null); /** * Delete the Stock data by stockId. If stock is not found do nothing * * @param int $stockId * @return void * @throws \Magento\Framework\Exception\CouldNotDeleteException */ public function deleteById($stockId); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースとストックをマッピングするためのサービス

クライアントAPI（ビジネスロジックコード内）のボイラープレートコードの数を減らすために、「 クライアントにできることを何もさせない 」というルールに従って、データインターフェースSourceStockLinkInterfaceを導入しません 。 代わりに、SourceをStockに割り当てるための一連のドメインベースのサービスコマンドを導入します。



その結果、3つのコマンドが取得されます。

 interface AssignSourcesToStockInterface { /** * Assign list of source ids to stock * * @param int $stockId * @param int[] $sourceIds * @return void * @throws \Magento\Framework\Exception\InputException * @throws \Magento\Framework\Exception\CouldNotSaveException */ public function execute(array $sourceIds, $stockId); } interface GetAssignedSourcesForStockInterface { /** * Get Sources assigned to Stock * * @param int $stockId * @return \Magento\InventoryApi\Api\Data\SourceInterface[] * @throws \Magento\Framework\Exception\InputException * @throws \Magento\Framework\Exception\LocalizedException */ public function execute($stockId); } interface UnassignSourceFromStockInterface { /** * Unassign source from stock * * @param int $sourceId * @param int $stockId * @return void * @throws \Magento\Framework\Exception\InputException * @throws \Magento\Framework\Exception\CouldNotDeleteException */ public function execute($sourceId, $stockId); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

API vs SPI

このプロジェクトのフレームワーク内で、拡張機能を改善し、コンポーネントの接続性を減らすために、 サービスプロバイダーインターフェイス （SPI）からAPI（アプリケーションプログラミングインターフェイス）を明示的に分離することが決定されました。

• リポジトリはAPIと見なすことができるため、リポジトリインターフェースのメソッドはビジネスロジックのPHPコードで呼び出されると想定されています。
• リポジトリ実装クラスがメソッドをプロキシする個別のコマンドクラス（Get、Save、GetList、Deleteなど）は、現在のシステム動作を拡張または置換するためにサードパーティの実装を提供できるSPIインターフェイスと見なすことができます。

したがって、たとえば、 Magento \ Inventory \ Model \ StockRepositoryリポジトリの実装は次のとおりです。

 /** * @inheritdoc */ class StockRepository implements StockRepositoryInterface { /** * @var SaveInterface */ private $commandSave; /** * @var GetInterface */ private $commandGet; /** * @var DeleteByIdInterface */ private $commandDeleteById; /** * @var GetListInterface */ private $commandGetList; /** * @param SaveInterface $commandSave * @param GetInterface $commandGet * @param DeleteByIdInterface $commandDeleteById * @param GetListInterface $commandGetList */ public function __construct( SaveInterface $commandSave, GetInterface $commandGet, DeleteByIdInterface $commandDeleteById, GetListInterface $commandGetList ) { $this->commandSave = $commandSave; $this->commandGet = $commandGet; $this->commandDeleteById = $commandDeleteById; $this->commandGetList = $commandGetList; } /** * @inheritdoc */ public function save(StockInterface $stock) { $this->commandSave->execute($stock); } /** * @inheritdoc */ public function get($stockId) { return $this->commandGet->execute($stockId); } /** * @inheritdoc */ public function deleteById($stockId) { $this->commandDeleteById->execute($stockId); } /** * @inheritdoc */ public function getList(SearchCriteriaInterface $searchCriteria = null) { return $this->commandGetList->execute($searchCriteria); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンストラクターは、提供される各操作に対して一連のコマンドインターフェイスを受け入れます。 そして、リポジトリからのパブリックメソッドの呼び出し中-呼び出しは適切なコマンドにプロキシされます。



SPIコマンドインターフェイスは次のとおりです。

 /** * Save Stock data command (Service Provider Interface - SPI) * * Separate command interface to which Repository proxies initial Save call, could be considered as SPI - Interfaces * so that you should extend and implement to customize current behaviour, but NOT expected to be used (called) in the code * of business logic directly * * @see \Magento\InventoryApi\Api\StockRepositoryInterface * @api */ interface SaveInterface { /** * Save Stock data * * @param StockInterface $stock * @return int * @throws CouldNotSaveException */ public function execute(StockInterface $stock); } /** * Get Stock by stockId command (Service Provider Interface - SPI) * * Separate command interface to which Repository proxies initial Get call, could be considered as SPI - Interfaces * that you should extend and implement to customize current behavior, but NOT expected to be used (called) in the code * of business logic directly * * @see \Magento\InventoryApi\Api\StockRepositoryInterface * @api */ interface GetInterface { /** * Get Stock data by given stockId * * @param int $stockId * @return StockInterface * @throws NoSuchEntityException */ public function execute($stockId); } /** * Delete Stock by stockId command (Service Provider Interface - SPI) * * Separate command interface to which Repository proxies initial Delete call, could be considered as SPI - Interfaces * that you should extend and implement to customize current behaviour, but NOT expected to be used (called) in the code * of business logic directly * * @see \Magento\InventoryApi\Api\StockRepositoryInterface * @api */ interface DeleteByIdInterface { /** * Delete the Stock data by stockId. If stock is not found do nothing * * @param int $stockId * @return void * @throws CouldNotDeleteException */ public function execute($stockId); } /** * Find Stocks by SearchCriteria command (Service Provider Interface - SPI) * * Separate command interface to which Repository proxies initial GetList call, could be considered as SPI - Interfaces * that you should extend and implement to customize current behaviour, but NOT expected to be used (called) in the code * of business logic directly * * @see \Magento\InventoryApi\Api\StockRepositoryInterface * @api */ interface GetListInterface { /** * Find Stocks by given SearchCriteria * * @param SearchCriteriaInterface|null $searchCriteria * @return StockSearchResultsInterface */ public function execute(SearchCriteriaInterface $searchCriteria = null); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのコマンドは、モジュールのSPIインターフェースを表し、名前空間の下にあります。

 Magento\Inventory\Model\Stock\Command\*
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

チームの実装は次のとおりです（ Magento \ Inventory \ Model \ Stock \ Command \ * ）。 たとえば、ストックを保存するコマンド：

 /** * @inheritdoc */ class Save implements SaveInterface { /** * @var StockResourceModel */ private $stockResource; /** * @var LoggerInterface */ private $logger; /** * @param StockResourceModel $stockResource * @param LoggerInterface $logger */ public function __construct( StockResourceModel $stockResource, LoggerInterface $logger ) { $this->stockResource = $stockResource; $this->logger = $logger; } /** * @inheritdoc */ public function execute(StockInterface $stock) { try { $this->stockResource->save($stock); return $stock->getStockId(); } catch (\Exception $e) { $this->logger->error($e->getMessage()); throw new CouldNotSaveException(__('Could not save Stock'), $e); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

製品予約メカニズム

予約オブジェクトは、注文の作成と特定の物理的な倉庫での商品数の減少の間に、販売する商品の現在のレベルを保持するために作成されます。

前のパートで詳しく説明した、発注のビジネスシナリオの実装。



冗長性のためのデータインターフェイスを導入

 /** * The entity responsible for reservations, created to keep inventory amount (product quantity) up-to-date. * It is created to have a state between order creation and inventory deduction (deduction of specific SourceItems) * * @api */ interface ReservationInterface extends ExtensibleDataInterface { /** * Constants for keys of data array. Identical to the name of the getter in snake case */ const RESERVATION_ID = 'reservation_id'; const STOCK_ID = 'stock_id'; const SKU = 'sku'; const QUANTITY = 'quantity'; const STATUS = 'status'; /**#@+ * Reservation possible statuses. */ const STATUS_OPEN = 1; const STATUS_CLOSED = 2; /**#@-*/ /** * Get Reservation id * * @return int|null */ public function getReservationId(); /** * Get stock id * * @return int */ public function getStockId(); /** * Get Product SKU * * @return string */ public function getSku(); /** * Get Product Qty * * @return float */ public function getQuantity(); /** * Get Reservation Status * * @return int */ public function getStatus(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

予約はAppend-Only不変のエンティティとして認識されるため、ReservationInterfaceに修飾子（セッターメソッド）は必要ありません。 したがって、予約オブジェクトを作成するには、ReservationBuilderInterfaceが必要です。

 $reservationBuilder->setStockId(1); $reservationBuilder->setSku('sku'); $reservationBuilder->setQty(10); $newReservation = $reservationBuilder->build(); //now we could save Reservation entity $reservationAppend->execute([$newReservation]);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

オブジェクト予約サービス

予約（予約）を追加するサービスは、注文、注文の処理、または注文のキャンセル時に使用されます。 返品操作の作成と処理だけでなく この時点で、SKUごとに1つの予約パックが作成され、このサービスを使用して処理のために追加されます。

 /** * Command which appends reservations when order placed or canceled * * @api */ interface ReservationAppend { /** * Append reservations when Order Placed (or Cancelled) * * @param Reservation[] $reservations * @return void * @throws \Magento\Framework\Exception\InputException * @throws \Magento\Framework\Exception\CouldNotSaveException */ public function execute(array $reservations); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のサービスは、注文の際にシステムがStockItemエンティティ（仮想集計）を処理するため、Event Stockの性質に起因するレイテンシでQuantity StockItemが更新されるため、販売可能な商品の正確な数量（数量）を計算するために使用されますどの物理ストア（ソース）の廃止措置が発生するかはわかりません。 したがって、注文の処理と処理の間に一定の時間が経過する場合があります。

 /** * Command which returns Reservation Quantity by Product SKU and Stock * * @api */ interface GetReservationQuantityForProduct { /** * Get Reservation Quantity for given SKU in a given Stock * * @param string $sku * @param int $stockId * @return float */ public function execute($sku, $stockId); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各予約は、開いた状態または閉じた状態にすることができます。

予約は変更できない不変オブジェクトであるため。 予約のステータスを変更する代わりに、2番目の予約を作成し、最初の予約をキャンセルします。

例えば

30個の商品を注文すると、予約が作成されます。

ReservationID-1、StockId-1、SKU-SKU-1、数量-（- 30 ）、ステータス-OPEN

この注文を処理したら、別の予約を作成します

ReservationID-2、StockId-1、SKU-SKU-1、数量-（ +30 ）、ステータス-閉店



合計で、これら2つのリザーブ（-30）+（+30）= 0は、StockItemに格納されている数量に影響しません。

ここで2つのことに注意することが重要です。予約は他のビジネスオペレーションに結び付けることができるため、予約オブジェクトと注文（注文）の間にバインディング（バインディング）を導入しません。 倉庫（在庫）の観点から見ると、商品を出荷して在庫を減らす必要がある注文番号は重要ではありません。

予約に負の値と正の値を使用すると、StockItemに格納されている数量から減算する必要がある合計数の計算が簡単になります。



たとえば、次のクエリを使用します。

 select SUM(r.qty) as total_reservation_qty from Reservations as r where stockId = {%id%} and sku = {%sku%}
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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

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



開発が進行中であり、コミュニティエンジニアが関与しているオープンプロジェクト、およびプロジェクトとドキュメントの現在のステータスに精通することができる場所は、 ここから入手できます 。



詳細なドキュメント

• MSIサービス契約 （英語）
• ご予約