REST APIリソースをビジネスドメインに基づいた領域に分割する

いくつかの関連ドメインをカバーする主要なアプリケーションREST APIでは、リソースが属するビジネスドメインに基づいてリソースを「エリア」に分割する方が理にかなっていますか、それとも単一のモデルを維持する方が良いですか？

たとえば、「販売」と「在庫」のサブドメインがあります。システムのユーザーは通常、一度に1つのドメインのみを考慮しますが、例外が発生する可能性もあります。両方のドメインに存在する「アイテム」の概念があるため、「アイテム」リソースを2つの異なる方法で実装できます。

1. 各ドメインの概念を表すさまざまなリソースがあり、各リソースは関連データのみを保持しています。

   / sales / items /：id

   / inventory / items /：id

2. すべてのコンテキストで使用されるすべてのデータを含む単一のリソースがあります。

   / items /：id

ドメインの1つだけに属するリソースもたくさんあります。

「地域」の長所

• 単一ドメインのみに関心があるユーザー向けのAPIを理解しやすくする
• リソースの実装が簡単（一度に読み取る/更新する項目が少ない）
• 特定のドメインごとにリソースをより特殊化/最適化できます
• より詳細なレベルでリソースへのアクセスを制御する機能

単一の統合モデルの長所

• 複数のドメインに属するコンセプトの重複リソースはありません
• ユーザーが複数のドメインで作業する必要がある場合は、すべてのニーズに対応する単一のAPIを使用するだけで済みます

上記のAPIパーティショニングは、APIコントラクトと実装の両方の複雑さを軽減する有効な方法ですか？私はそれがどこにも言及されているのを見たことがありません。

どちらかのアプローチを支持して決定を下すために検討する必要があるものは他にありますか？

これは、ドメインドリブンデザインの境界コンテキストパターンに最適です。

大きなモデルは適切にスケーリングされないため、小さなモデル（境界コンテキスト）に分割し、それらの関係（共通のエンティティ、境界コンテキスト間の相互作用など）を明示的に宣言することをお勧めします。

この場合、1つの共有リソース（アイテム）を持つ2つの境界コンテキスト（販売と在庫）があります。販売コンテキストでのアイテムの解釈は、在庫コンテキストでの解釈とは少し異なる場合がありますが、それで十分です。

このパターンを使用するには、次のことを行う必要があります。

• 異なるコンテキストの境界を特定します（サブルート/ sales /および/ inventory /を作成することで部分的に行いました）
• 共有リソース（アイテム）を識別し、さまざまな境界コンテキストにおけるリソースの解釈を明確に説明する
• 境界付きコンテキスト間の相互作用を特定します（これはおそらくこの質問の範囲外です）

注意事項

単一の統合モデルの長所：複数のドメインに属する概念の重複リソースがない

RESTの観点からは、リソースは複製されません。1つのリソースは複数のURIで識別でき、それぞれが異なる表現を持つことができます（指定された境界コンテキストに適合）。

経験則は次のようにすべきだと思います。

アイテム自体が売上や在庫に関係なく考えられない場合は、オプション1を選択してください。

アイテムが販売/在庫との関係なしに存在する可能性がある場合、またはこの関係がアーキテクチャーでそれほど強くない場合は、オプション2を選択できます。