概要
Java読書会でせっかく勉強したのにつぎつぎと忘れていくので、印象に残ったところを記録していく
2章 サービスへの分割
- アーキテクチャとはなにか？
- どうやってサービスに分割するか？
アーキテクチャとは？
- アーキテクチャとは、ソフトウェア要素とその関係性
- 4 + 1ビューモデル
- 論理ビュー：クラス構成、パッケージ構成とそれらの依存関係
- 実装ビュー：jarやwarの配置と、それらの依存関係
- プロセスビュー：プロセスとプロセス間通信
- デプロイビュー：マシンとネットワーク
- アーキテクチャが重要なのは、品質属性に関わるから
- 特にマイクロサービスはメンテナンス性やデプロイ容易性に影響する
- アーキテクチャスタイル
- 建築様式
- 寺院を建てるのにもXXX様式が複数ある
- 論理ビューについてのアーキテクチャスタイル
- 階層アーキテクチャ
- お馴染みの3層アーキテクチャなど分かりやすいやつ
- 実際のところ本当に上位層が下位層に依存しているかと言えば、DIなどがあるのでかならずしもそうではないし、上位が下位に依存するばかりだとテストもしづらい
- ヘキサゴナルアーキテクチャ
- ビジネスロジックを中心に考え、他の要素はビジネスロジックに依存するが、ビジネスロジックは他の要素に依存しないようにする
- ビジネスロジックから永続層や外部サービスを呼び出す場合は、ビジネスロジック層の方にインタフェース定義を置く（アウトバウンドポートと呼んでいる）
- 永続層や外部サービスを呼び出すための実装は、ポートの実装を用意する（アウトバウンドアダプタ）
- こうすることで依存関係の向きを、呼び出しの向きとは逆にする。あとはDIで注入するなりする
- 本書では論理ビューとしては、こちらを推している
- 階層アーキテクチャ
- 実装ビューに関するアーキテクチャスタイル
- Monolithic architectureパターン
- お馴染みの一枚岩
- Microservice architectureパターン
- 本書のテーマとなっている個別デプロイ可能なサービスの集合体
- Monolithic architectureパターン
マイクロサービスアーキテクチャ
-
マイクロサービスアーキテクチャを定義するための3ステップ
- システム操作の洗い出し
- サービスの洗い出し
- 各サービスのAPIの定義と連携方法の定義
-
システム操作の洗い出し
- とりあえずユーザーシナリオはあるとする
- いわゆるオブジェクト指向分析的な方法でドメインモデルを作る（例えば名詞抽出法など）。この段階では荒いもので良い
- システム操作を抽出する
-
サービスの洗い出し
- Decompose by business capabilityパターン
- 業務を細分化していって、手頃な粒度になったらそれをサービスとする
- Decompose by sub-domainパターン
- DDD由来の方法。
- DDDでは、ドメイン全体を単一のモデルにするのではなく、サブドメインの集合体としてモデリングする
- サブドメインとサービスを一対一に対応させる
- サブドメインに分割する方法は本書では述べられていない代わりに、分割後のサブドメインの概要が書いてある
- FTGOではOrderという概念が中心になるが、受注サブドメインと、配達サブドメインと、キッチンサブドメインでは持つべき情報も異なるし、呼び方も異なるかもしれない。配達サブドメインではDeliverであり、キッチンサブドメインではTicketであるが、単一モデルだとOrderに集約されてしまう
- 上記のように一つの概念が別々に見える場合はサブドメインとして分かれる。一方でサブドメイン内では概念についての共通認識が持てる。
- Decompose by business capabilityパターン
-
サービスAPIの定義
- まずクライアントからのエントリポイントとなるサービスを見つける
- 複数サービスの連携が必要ならそれぞれAPIを定義する
まとめ
- アーキテクチャに関しては、ヘキサゴナルアーキテクチャが重要な考え方と思われる
- アプリケーションの中心はあくまでビジネスロジックであり、ここの部分を他の要素に依存させないことで再利用性やテスタビリティを高める
- 後半に関しては、Decompose by sub-domainパターンが大事
- サブドメインとは概念の境界なので、ここを超えると同じ概念と思っていたものが別のものとなる（実際は呼び方が同じだけで別概念）
- 概念の不一致は、ソフトウェアが発展する過程で、不具合の要因になったり、God Classのを生み出すもとになる
- 最初の段階できっちり概念境界を明確にするDecompose by sub-domainの方が、単に業務を細分化しただけのDecompose by business capabilityよりはより良い方法と言えるでしょう
- ただし、分析の難易度としては、Decompose by sub-domainの方が圧倒的に上でしょう。
- このあたりは本書よりもDDD本の領域なので詳しくは述べられてはいない。
- DDDに少し興味を持った