あけましておめでとうございます。雑煮とお酒と3歳児と遊ぶ年始を過ごしながらO'Reillyのマイクロサービスアーキテクチャ本感想の第2回です。
3章「サービスのモデル化方法」を読んで
3章では実際にマイクロサービスをどのように実践していくかの手始めとして、サービスの境界について説明がされています。
優れたサービスにするための疎結合と高凝集性
本章以前でも触れられていた疎結合と高凝集性について改めて語られています。絶対に忘れてはいけない非常に大切な2つの概念であると位置づけており、一言でいうと以下になります。
- 疎結合とは、特定のサービスへの変更が他のサービスへ影響しない状態であること
- 高凝集性とは、振る舞いが同じものを適切にまとめること
コンテキスト境界という考え方
続いてコンテキスト境界(Bounded Context)という言葉が出てきます。こちらもマイクロサービスの概念を語るうえでとても重要な用語でありエリック・エヴァンスのドメイン駆動設計にも触れながら説明がされています。僕はざっくり1マイクロサービス＝1コンテキスト境界が理想という理解をしました。
- ドメイン、事業全体を差す大きな枠（詳しくはDDDを読んだ方がよさそう）
- コンテキスト境界、ドメイン内で異なるコンテキストごとにまとめたもの
- コンテキスト境界内には以下の二つのモデルがある
- 隠れモデル、他のコンテキストへ見せる必要がないもの
- 共有モデル、他のコンテキストと共有するもの
- インターフェース、共有モデルを実際に受け渡しするエンドポイント
外へ見せる必要の無いものを隠すことで疎結合の'疎'を実現しつつ、コンテキスト毎にまとめることで高凝集性を高めること、それがコンテキスト境界であるといったところでしょうか。
モジュールとサービス
続いてモジュールについての説明がされますが「あれっ？」となりました。第1章の「1.4 他の分解テクニック - 1.4.2 モジュール」の項で、モジュールも蜜結合になりがちだから気をつけろというような文脈があるのですが「3.3.2 モジュールとサービス」ではモジュール化しましょうとあります。読みなおすと"コンテキスト境界内では"モジュール化をするべきで、それは隠れモデルと共有モデルを体現したコードベースであることが望ましく、そのモジュールがそのまま一つのマイクロサービスの候補となります。
コンテキスト境界を定義する方法アレコレ
その後はどのように境界を定義するかの話が続きますが、GoCDにおける失敗談（早く分割し過ぎて定義を失敗し、一度モノリシックにして再び分割しなおした）で釘を刺しつつ以下が挙げられます。
- ビジネス機能では該当サービスが何のデータを他サービスへ提供するかを考えるのは二の次で、とにかく機能を先に考えることが重要
- データに着目して分割すると機能不足になりがちだから
- コンテキスト境界内での分割も進めていくべし（共有モデルには影響しないように）
- とはいえ技術的な観点からも注意して分解すること
- 毎回泣かされるからオニオンアーキテクチャとか笑う
3章の感想
3章はコンテキスト境界という概念を学ぶための章だったなという感想です。こういった高水準（技術よりではないという意味）な内容は、概念を定義するための用語がバンバン出てきて正直初見は辛いのですが、"コンテキスト境界"のように言葉として定義されることで理解が進むんですよね。分解の方法については読んでいる分には当たり前なんですが、実業務だと同じ失敗をしそうですが、本書を読んだことですぐに失敗に気づけることを願います。
