MicroServiceについてお勉強読書をしたので、少しずつまとめていくことにする。
3章 サービスのモデル化方法
3章では、マイクロサービスの境界に関する説明を、架空のサービスを例に挙げて説明している。
例：MusicCorp
マイクロサービスがどのように機能するかを説明するため、架空のサービスMusicCorpを設定する。
MusicCorpは音楽CDのオンライン販売を行うサービスである。
優れたサービスにするには
優れたサービスにする2つの主な概念として、疎結合と高凝集性がある。
疎結合
マイクロサービスの本質は、システムの他の部分を変更する必要なしに、あるサービスを変更してデプロイできることにある。そのためにサービスが疎結合であることが必要である。
サービスの密結合を生み出す典型的な誤りは、サービス同士が密に結合する統合方式を選び、サービス内の変更によってコンシューマの変更が必要になることである。これの回避方法については4章で述べる。
高凝集性
高凝集性とは、関連する振る舞いを一緒に、関連しない振る舞いを別の場所に配置することである。それにより振る舞いを変更するとき、1か所の変更ですみ、その変更を早くリリースできる。
高凝集性を実現するためには、関連する振る舞いが1か所に存在し、他の境界との通信が出来る限り疎になるようドメイン内の境界を探す必要がある。
境界づけられたコンテキスト
この考え方では、どのドメインも複数の境界づけられたコンテキストからなり、それぞれのコンテキストには外部と通信する必要のないモデルと、外部の他のコンテキストと共有されるモデルがある。境界づけられたコンテキストから情報が欲しい場合や、境界づけられたコンテキスト内の機能を要求したい場合は、モデルを使用して明示的な境界と通信する。
MusicCorpの事業を例にとると、ドメインは運営する事業全体になる。このドメインで境界づけられたコンテキストの例として、倉庫と経理を挙げる。
共有モデルと隠れモデル
MusicCorpでは、経理部門と倉庫を2つの別個の境界づけられたコンテキストとみなせる。
経理部門には、倉庫の詳細な内部作業の知識は必要ないが、在庫水準を把握し、帳簿を最新の保つ必要がある。そこで、在庫品目が経理部門と倉庫のコンテキスト間の共有モデルになる。
しかし、倉庫のコンテキストから在庫品目に関するすべてをやみくもに公開する必要はないことに注意する。そのため、内部専用の表現と公開する外部表現がある。
モジュールとサービス
新しいコードベースを始めるときは、プロセス境界内でモジュールを使用して関連するコードをまとめ、システム内の他のモジュールとの結合を減らすところから始めるのが良い。ドメインで境界づけられたコンテキストが見つかったら、コードベース内では共有モデルと隠れモデルを備えたモジュールとしてモデル化をするようにするとよい。
このようなモジュール境界は、マイクロサービスの優れた候補となる。一般に、マイクロサービスは境界づけられたコンテキストときれいに一致するようにするからである。サービス境界がドメイン内の境界づけられたコンテキストと一致し、マイクロサービスが境界づけられたコンテキストを表していれば、マイクロサービスを疎結合で高い凝集性を持たせるためのよいスタートを切ることが出来る。
時期尚早な分解
初めてのドメインでは、システムをマイクロサービスに分解するのが時期尚早だとコストがかかってしまう場合がある。例えば、数か月後にサービス境界の最初の解釈があまり正しくなかったことが判明したときなどである。その場合、開発したマイクロサービスを一度モノリシックシステムにマージし、適切な境界位置を理解した後、再度マイクロサービスに分解することになる。
マイクロサービスに分解したい既存のコードベースがある方が、最初からマイクロサービスに取り組みよりはるかに簡単である。
ビジネス機能
組織に存在する境界づけられたコンテキストについて考える際、共有するデータの観点ではなく、そのコンテキストが残りのドメインに提供する機能について考えるべきである。サービスとしてモデル化する際は、この機能がネットワーク経由で他のコラボレータに公開される主要な操作になる。
入れ子になったサービス
マイクロサービスの境界を検討するときには、まず大きく粒度の荒いコンテキストの観点で考え、それから入れ子になったコンテキストに沿って分解し、接合部で分割する利点を求める。入れ子になったコンテキストは他の連携するマイクロサービスから隠したままにすると効果的である。
完全に分離する手法と入れ子にする方法のどちらを選ぶかは、組織構造に基づくべきである。例えば倉庫の機能を注文フルフィルメント、在庫管理、入荷に関連する機能に分割するとき、それぞれを異なるチームが管理している場合は、恐らくトップレベルマイクロサービスが理にかなっているだろう。一方、1チームで管理している場合は、入れ子になったモデルの方が理にかなっている。
技術的境界
技術的な接合部に沿ってサービス境界をモデル化することは、必ずしも間違いではない。しかし、これは接合部を探すための第一条件ではなく、第二条件であるべきである。第一条件としては、ビジネスに焦点をあててシステムを分割することを考えるべきである。
3章まとめ
3章では優れたサービスにする方法と、問題ドメインでの疎結合と高凝集性の利点が得られる接合部の探し方について述べた。境界づけられたコンテキストはこのような接合部を探すのに便利なツールであり、マイクロサービスをこれらの境界に一致させることで、マイクロサービスの利点を得られやすくなる。次回以降はさらに技術的な話に踏み込んでゆく。