DDDリポジトリのクエリ言語

Question

現在、私はモノリスREST APIをマイクロサービスに分割するように取り組んでいます。 Domain Driven Design（現在学習中）をご紹介したいと思います。この時点で私の最大の懸念はRepositoryを実装することです。

ドメインUBIQUITOUS LANGUAGEはProfileエンティティ（ソーシャルメディアプロファイル、例えばTwitterプロファイル）を定義します。私は別のマイクロサービスにProfileを抽出することを考えています。プロファイルを照会するには、私はProfileRepositoryを紹介します。

APIゲートウェイを含む他のマイクロサービスには、独自のProfile検索パターンがあります。これらすべての検索パターンを満たすためにリポジトリを設計する方法を教えてください。クエリごとにfindメソッドを作成する必要がありますか？何らかの動的クエリ言語を導入すべきでしょうか？

モノリスアーキテクチャでは、複数のリポジトリを作成できました。ユースケースごとに1つ。マイクロサービスアーキテクチャでは、他のマイクロサービスが新しいクエリを必要とするたびにProfileの責任を負うマイクロサービスを変更する必要があります。

Answer 1

動的クエリ言語を追加することで、別のレベルの複雑さがもたらされます。私の個人的な意見は、本当に必要な場合（つまり他の人がシステムをたくさん統合する場合）あなたの投稿に対する@plalxのコメントに強く同意します。複雑さを加えることは常に価格を持ち、それは両方向に行きます。

ユビキタス言語について&用語集 - 実際にはドメイン内で重複する用語を避けるべきです。ソーシャルメディアアカウントに関する「プロファイル」は、「SocialProfile」と命名することができます。したがって、「プロファイル」が2つの異なる状況で2つの異なるものを意味する場合、それらの1つのより良い用語を見つけようとします。確かに、「APIゲートウェイ」のコンテキストで「プロファイル」が何かであることを知ることができますが、同時にそれは他のコンテキストでは他のものですが、これは長期的には良いことではありません。あなたが「プロフィール」と呼ぶものの数を説明することができます。あなたの最後の質問で

：モノリスアーキテクチャで

私は複数のリポジトリを作成することができます。ユースケースごとに1つ。マイクロサービスアーキテクチャでは、他のマイクロサービスが新しいクエリを必要とするたびに、プロファイルを担当するマイクロサービスを変更する必要があります。

あなたのアーキテクチャによりますか？あなたのマイクロサービスは同じコードベース&リポジトリクラスを使用していますか？彼らは同じ名前空間にいますか？それぞれのマイクロサービスが使用する1つのリポジトリを持つことができます。これは、異なるマイクロサービスが異なることを行うため、論理的なアプローチです。 あなたが私のアドバイスを受けて、あなたのドメイン内の各エンティティの具体的な用語を見つけたら、これを疑問に思う必要はありません。 :)

私のプラクティスからのREST APIの副メモ： APIが本当にRESTの場合は、各エンドポイントの背後にあるリポジトリを使用できます。しかし、APIエンドポイントがデータ（またはエンティティ）を返すだけでなく、何かをしている場合、 - APIはおそらくRESTではなくプレーンなRPC - あなたのオブジェクトエンドポイントの背後での使用は最も可能性の高いサービスであり、リポジトリではない