はじめに

私は以前から、マイクロサービスはオブジェクト指向モデルの一種であり、オブジェクト指向プログラミングによるアプリケーションの設計とマイクロサービスの設計には多くの共通点があるのではないかと考えていました。

自分の考えの整理を兼ねて、アプリケーション設計とマイクロサービスの設計についてつらつらと書いていきます。

※ この記事では、マイクロサービスにおける 1 サービスを「アプリケーション」と呼び、1 アプリケーション内の設計を「アプリケーション設計」と呼んでいます。

レイヤー構成

アプリケーションを実装する際、トップレベルで考えるアーキテクチャは、

といった、レイヤー構成に関するものです。¹

最近ではクリーン・アーキテクチャを見かけることが多いです。

マイクロサービスのレイヤー構造としては、BFF (Backends For Frontends) というデザインパターンがあります。
以下は、BFF を説明する図です。

これら 2 つの図は全然違うように見えるかもしれませんが、実はかなり似ています。

BFF によるマイクロサービスの図を円形にすると、以下のようになります。

クリーン・アーキテクチャの図と見比べると、

が、それぞれ対応するように見えます。

これらの対応について、もう少し考えてみます。

クリーンアーキテクチャの図で Use Cases と書かれた層は、アプリケーション層とも呼ばれます。
この層の責務は、ドメインモデルのインターフェースを利用してユースケースを実現することや、トランザクションなどのアプリケーション都合のロジックを実現することです。

マイクロサービスにおける BFF は、マイクロサービス全体におけるアプリケーション層の役割を果たします。
BFF は、アプリケーションにおけるアプリケーション層と同様、背後にあるコアなドメインの API をファサードし、ユースケースを実現するのです。

マイクロサービスにおけるトランザクション管理では Saga というデザインパターンが有名ですが、その Orchestration 型の実装も、「アプリケーション層がトランザクションを実現する」と近いものを感じます。

アプリケーションにおいて、ドメインモデルはデータ (フィールド) を隠蔽して外部に振る舞い (メソッド) を提供するオブジェクトとして実装されます。
データを隠蔽して外部に振る舞いを提供するというのは、オブジェクト指向のコアな考え方です。

マイクロサービスにおいてアプリケーション間でデータベースを共有することは避けるべきとされており、データ (データベース) を隠蔽して振る舞い (API) を提供するというのは、まさにオブジェクト指向です。

マイクロサービスにおいて共有データベースはアンチパターンと言われますが、これは「オブジェクト指向的な設計」という観点からも当然のことなのです。

ドメインモデルにおいて、データの永続化は「集約 (Aggregate)」という単位で扱います。
「集約」をマイクロサービス的に言うと、「1 アプリケーション」に相当するのではないでしょうか。

アプリケーション設計の文脈では、集約をまたがる永続化について、オブザーバーパターンを適用するなどして疎結合な実装にする場合があります。
マイクロサービスをまたがる処理についても、キューなどを利用して疎結合に実装する場合があります。

なんとなく「マイクロサービスと OOP の設計は共通点が多そうだな」と感じたことをつらつらと書いてみました。
(これだけの内容ではどう活かせるのかもはっきりしませんが...)

考えてみれば当たり前の話ではありますが、マイクロサービスにオブジェクト指向の原則を適用するという記事もいくつかありました。

以上、何の役に立つかも分からないポエムでした。