ITとかCockatielとか

技術のこととか。飼鳥(オカメインコ)のこととか。気になったこととか。基本的には備忘録。

マイクロサービスアーキテクチャ 第3章

3章 サービスのモデル化方法

優れたサービスにするポイント

疎結合

  • マイクロサービスの本質は、あるサービスを変更しても別のサービスの変更が必要ないこと。(とても重要!)
  • 連携するサービスについては、必要最低限のことしか把握しない。(それでよい、そうであるべき)

高凝集性

  • 関連する振る舞いはまとめ、そうでないものは別にする。
  • 振る舞いを変更する場合、1箇所で変更でき、素早くリリースできるようになる。
  • そうでない場合、多くのサービスを同時に開発するため遅くなり、それをリリースするリスクが高くなる。

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

  • Bounded Context, BC, コンテキスト境界、境界コンテキスト
  • Eric Evans著より。
  • コンテキストには、外部と通信する必要のないもの(隠れモデル)と、外部と共有すべきもの(共有モデル)がある。
  • これらを整理することで、「境界付けられたコンテキスト」が明らかになる。

※コンテキストの単位は、例えば「倉庫」と「経理」。倉庫の隠れモデルは棚や注文のピッキングがある。共有モデルは在庫品目があり、経理と共有されることになる。

モジュール・サービス

  • 「境界付けられたコンテキスト」を整理したら、「共有モデル」(他のコンテキストと共有するもの)と「隠れモデル」(内部だけで完結するもの)を備えたモジュールとしてモデル化する。
  • このモジュール境界がマイクロサービスの候補になる。
  • サービス化(マイクロサービスとして分割)において、サービス境界を間違えると改修が高コストになるため、新規システムではよりモノリシックな状態にしておく方が賢明である。あとで分割を進めればよい。(ThoughtWorksの例では境界を誤り、一度モノリスにしてから再度分割を行った。)
  • サービス境界(マイクロサービス)がコンテキスト境界と一致していれば、高い凝集性を持った状態になる。

ビジネス機能

  • 組織のコンテキスト境界の観点は、そのコンテキストが他のドメインに提供する機能を考えるべきである。(データではない)
  • 機能には情報交換(共有モデル)が必要になることもあるが、そこに注目してしまうとCRUDになる。それはよくない。
  • 「このコンテキストは何を行うか」「それを行うためにはどんなデータが必要か」を考える。
  • サービスの機能は操作を通してモデル(データ)が共有される、ということ。

トップレベ

  • コンテキスト境界で共有されるモデルはトップレベルコンテキスト(トップレベルマイクロサービス)となる。
  • その他のモデルは隠れモデルのまま(入れ子構造)とするか、共有モデル(トップレベルモデル)とするかという選択肢がある。
  • そのように選択するかは、組織構造に基づくべきである。(ex.組織が同一なら隠れモデルとする。)

ビジネス観点での通信

  • システムの変更は、ビジネス観点での振る舞いを変更することである。
  • サービス間の通信もビジネス観点で考えるべきである。
  • サービス間の通信形式を考えることは、組織内(組織間?)の書類形式を考えることと同様の価値がある。

技術的境界

  • 技術観点で境界を設ける方法もあるが、これが第一条件であってはならない。
  • 例えば、通信形式を変更したい場合、垂直方向の分割がされていると変更箇所が多岐に渡るためコストがかかる。技術的観点が必ずしも悪いわけではないが、あくまでも第二条件であるべき。