ドメインモデルをMicroservicesに落とし込む

Microservicesでサービス境界設計を行うためのドメイン分析という記事で、 ビジネス要件をDDDのアプローチで分析する方法について書いた。

この記事では、どのようにシステムレイヤーに落とし込むかについて書いていく。

境界付けられたコンテキスト

まず、境界付けられたコンテキストをサービスにできないか検討する。 基本的に、サービスは複数の境界付けられたコンテキストにまたがってはいけない。 境界付けられたコンテキストは、特定のドメインモデルの境界であると定義されるため、 複数の境界付けられたコンテキストにまたがるサービスは、複数の仕事を持ってしまっていることになる。

集約

集約をサービスにすることは多い。 集約をサービスにすることは、以下のような意味を持つ。

  • ビジネス要件的に切り離せないかたまりを意味している
  • 凝集度が高い
  • 複数の集約は、疎結合である

ドメインサービス

ドメインサービスもサービスとして適している。 ドメインサービスは、複数の集約に対するステートレスな操作である。

これら以外に、チームの規模や技術的習熟度、スケーラビリティ、可用性などによって、 サービスを分割したり、結合したりすることで、Microservices設計のたたきを作る。

設計の検証

以下のような検証をする。

  • 各サービスがひとつの役割を持っていること
  • サービス間での呼び出しが頻繁に行われないこと
    • 頻繁な通信が発生しそうな場合、まとめられるかもしれない
  • 各サービスが、小さなチームで開発/オペレーションできる程度に小さいこと
  • 各サービスが、依存関係なくデプロイができること

また、サービスを細かくするか悩むときは、荒いままにしておくほうが良い。 ひとつのサービスをふたつの小さいサービスに分割することは難しくないことが多い。

システムに落とし込む

Microservicesを設計したら、それをどのようなシステムアーキテクチャで運用するかを検討する。 選択肢は多くの場合ふたつ。

  • サービスオーケストレータ
  • FaaSを提供するサーバーレスプラットフォーム

パブリッククラウドを採用する場合、前者はGKE(GCP), EKS(AWS), AWS ECSなどが候補である。 後者はCloud FunctionsやAWS Lambdaを使用する。 メジャーなパブリッククラウドであれば、これらは提供されているだろう。

サービスオーケストレータ

サービスオーケストレータは、各サービスのデプロイ、管理、スケールをマネージしてくれる。 また、サービスディスカバリ、監視なども提供されている。

コンテナは必要か?

Microservices == Containerではない。 Microservicesを始めるのに、コンテナは不要である。 しかし、コンテナのいくつかの利点は、Microservicesにとってもメリットが有る。

  • portability
    • コンテナイメージは、依存関係なく単一で実行できる。
  • density
    • Microservicesは、ひとつひとつの小さなサービスで構成されている。各サービスは少ないコンピューティングリソースで動作するため、コンテナのようにOSリソースを共有する場合にメリットが有る。

FaaS

ドメインイベントなどは、FaaSの利用を検討しても良い。

オーケストレータかFaaSかは、移植性、管理コスト、スケーラビリティ、価格などを考慮して検討する。 Mercariでは全面的にGKEを採用している。

まとめ

DDD的なアプローチでドメイン分析を行い、それをMicroservices/システムアーキテクチャに落とし込むやり方について書いた。 ここがMicroservicesで一番むずかしいと言っても過言ではないと思う。 ドメインベースの設計は反復的に、チームで訓練するような領域であると思う。 精進していく。