マイクロサービスのアーキテクチャと制限されたコンテキスト
ここ数日、私はマイクロサービスのアーキテクチャーについていくつか読んでいます。私はこれから始めたばかりなので、まだ全体のポイントはわかりませんでしたが、私の注意を引いたポイントが1つあります。ある意味では、マイクロサービスはDDDからの境界コンテキストのアイデアを活用する具体的な方法であるように思えます。
つまり、マイクロサービスは、私が理解しているように、完全なアプリケーションであり、疎結合であり、自己完結型です。通常、各マイクロサービスは独自のチームによって開発され、独自のコードベースを持ち、独立してデプロイされます。最終的に、彼らは協力して、開発中の完全なソフトウェアを形成します。
これは本当に境界のあるコンテキストのようです。もちろん、境界のあるコンテキストは概念のようなものです。マイクロサービスは、その概念を実際に実装する1つの方法のようです。
そうですか？マイクロサービスは、DDDからの境界コンテキストのアイデアを適用する特定の方法と考えることができますか？そうでない場合、それはなぜですか？そうでない場合は、理由を理解することで境界付きコンテキストとマイクロサービスの両方の理解が向上する可能性があると思います。
あなたの質問は カテゴリエラー だと思います。つまり、マイクロサービスはアーキテクチャを整理する方法であり、制限付きコンテキストはコードで操作するクラス/オブジェクトを整理する方法です。 2つの間に1対1の相関関係があるか、そうでない場合があります。コンセプト間に必要な関係は確かにありません。
Martin Fowlerの制限付きコンテキストの例を借りる場合：
この場合、境界のあるコンテキストは、サポートコンテキストで行うのとは異なる、セールスコンテキストで異なるProductクラスが必要であることを示しています。これらのクラスをどこにどのように格納または取得する必要があるかはわかりません。例えば：
これは、マイクロサービスなしで実装できます。これがインターネットと通信しない単純なリッチクライアントアプリケーションである場合、明らかにマイクロサービスはあまり意味がありません。
これは、コンテキストごとに1つのマイクロサービスで実装できます。おそらく、販売とサポートのコンテキストはそれぞれ単一のデータベースで表され、各データベースには単一のマイクロサービスがあります。次に、セールスマイクロサービスに問い合わせてSalesProductを取得し、サポートマイクロサービスに問い合わせてSupportProductを取得します。
または、オブジェクトタイプごとに1つのマイクロサービスを使用してこれを実装できます。販売情報とサポート情報の両方を格納する製品データベースが存在する場合があり、マイクロサービスに製品のいずれかのバージョンを要求できます。または、情報のblobのみを要求し、そのblobを使用して、SupportProductとSalesProductをインスタンス化することは別の場所で行われます。
マイクロサービスは、DDDからの境界コンテキストのアイデアを適用する特定の方法と考えることができますか？
彼らは、マイクロサービスと境界コンテキストの間の強力な関係を暗示しているという質問をしているのです。私はそれを誤解しています（しかし、多分それはあなたが何を意味していたのかではなく、言葉がどうやって出てきたかだけです）。
マイクロサービスは、DDDを実装している場合は、制限付きコンテキストを実装するのに適していると思います。
すべてのプロジェクトがDDDを使用しているわけではないことを覚えておいてください（そして、ほとんどのプロジェクトで、DDDを正しく使用していません）。これらの場合、マイクロサービスを適用できます。
境界付きコンテキストがマイクロサービスにどのように関係するべきかについては異なる意見があります。これらの意見のいくつかは、マイクロサービスがどのように定義されるかに主に基づいています。
1対1で対応すべきではないと言う人は、通常、マイクロサービスを物理的なサービスとして考えています。これはASP.NETアプリケーションのようなプロセスです。彼らは、多くのサービスが制限されたコンテキストを共有できると主張しています。マイクロサービスの定義が物理的なサービスである場合、私はそれらに同意します。
ただし、マイクロサービスは、物理的に複数のプロセスとして実装される可能性のあるAPIとして考える方が好きです。これらの用語では、マイクロサービスは複数のプロセス（Webサービス、同期ジョブなど）で構成できます。実際、CQRSを使用していて、読み取りがプロセスレベルで書き込みから分離されている場合、このマルチプロセス定義にほぼ従う必要があります。マイクロサービス。この定義に準拠する場合は、マルチプロセスマイクロサービスが個々の境界コンテキストに対応するのが最適だと思います。チームの編成と責任の分担により、認知の範囲に役立ちます。
マイクロサービスは、DDDからの境界コンテキストのアイデアを適用する特定の方法と考えることができますか？
私はそれに同意しますが、私はそれを別の方法で提起します。
境界付きコンテキストとは、具体的な境界またはフェンスを持つ任意の領域です。それらがマイクロサービスで実装されている場合、この境界はプロセスの境界と一致します（これは、念のため （micro-）service境界 の不十分な指標です）。独自の境界タイプを作成できます。たとえば、モジュールよりも高いレベルの、より高いレベルのプロジェクトディレクトリにすることができます。とにかく、これは境界コンテキストの概念を検討するための1つの「ランタイム」パースペクティブにすぎません。
たとえば、ドメインエキスパートはマイクロサービスが何であるかを知りません。彼または彼女の境界付きコンテキストは、特定の用語が意味をなし、特定の機能が存在し、独自のユビキタス言語が適用されるホワイトボード上の単なる視覚表現です。
最後に、ドメインを分解する方法と 境界コンテキストの定義 を理解することは、システムの全寿命に大きな影響を与えるため、台無しにしたくない重要なステップです。
制限付きコンテキストとマイクロサービスは似ていますが、（私の理解から）制限付きコンテキストは複数のマイクロサービスで構成できます。バウンドコンテキストの Martin Fowlerの説明 から、彼のイラストのバウンドコンテキストの各四角形は1つのマイクロサービスになる可能性があるため、チケット用、欠陥用などが考えられます。サービスは、バインドされたコンテキスト全体に対して1つのマイクロサービスまで、より大きなマイクロサービスに組み合わせることができます。