進化的アーキテクチャ 後半

khasegawa.hatenablog.com

の続き

5章 進化的データ

データベースのスキーマは、アプリケーションのクラスやクラス階層と同じで、具体的な物事を抽象化したものである.
この物事に変化があったならば、スキーマも変更すべきである.
そうでなければ、物事と抽象化したスキーマとの間の関係性には乖離が生じる.
スキーマの進化を容易にするためには、「テスト」「バージョン管理」「漸進的に進む」といった仕組みが必要である.
共有データベースという複数のアプリケーションが1つのデータベースを参照する場合、あるアプリケーションがスキーマ変更をした場合に、他のアプリケーションが動作しなくなるといったことが起こりうる.
ならば、スキーマの状態に古い状態と新しい状態を残し、古いスキーマを参照するアプリケーションがなくなったら、削除すれば良くなる.

所感

乖離が生じると、実装に対してのコストがかかるだけでなく、暗黙的なコンテキストが多く増えると思われる.
最初のうちはいいかもしれないが、これが数年続いた時のリスクやコストは馬鹿にできないもになっていても不思議ではない.
これは何もアプリケーションだけでなく、ビジネス・ドメイン要件側でもそういった考えをしておく必要はありそうな気がしている.

6章 進化可能なアーキテクチャの構築

進化可能なアーキテクチャを構築するためには、以下3つの手順を行う.

  1. 進化の影響を受ける次元を特定する
  2. 各次元に対して適応度関数を定義する
  3. デプロイメントパイプラインを使って適応度関数を自動化する

新規プロジェクトを進化可能なアーキテクチャに構築していくのは、既存プロジェクトを改良するよりかは遥かに容易である.
既存のアーキテクチャを改良するには、適切な結合適応度関数を考えておく必要がある.
この適切な結合を推進するためには、モノリスから大きなサービスが協調して動作するアーキテクチャに変えていく必要がある.
うまく分割できないときもあるが、それはライブラリといった形式でそれぞれのサービスに提供するのが良い.
可逆性のある仕組みを構築することも重要.
可逆性のある仕組みとは、Blue/Greenデプロイのようなデプロイメントパイプラインを構築することにある.
DDDでの腐敗防止層を、ライブラリやフレームワークといった外的要因に対して用意しておくことで、アップデート時の影響を最小限にしておくことができる.
ライブラリなどといった依存は、メリットをもらたす反面、制約を課すということを忘れてはならない.
この利益と代償を考えながらアーキテクチャを構築していく必要がある.
また現時点で最善を考えつつも、数年後にはアーキテクチャの再構築などがしやすいようにアーキテクチャを構築する犠牲的アーキテクチャというアプローチも重要である.

所感

アーキテクチャやアプリケーション開発に具体的な手法について述べられているが、インフラ的な観点は少ないように見受けられる.
DDDの思想がベースになっているため、DDDの勉強をしておく必要がありそう.
アーキテクチャを設計するうえで必要になる観点を改めて考えることができる章でもあったように感じる.

7章 進化的アーキテクチャの落とし穴とアンチパターン

ベンダーキングアンチパターン
ベンダー依存になり、ベンダーがいないとダメな構造になることは非常に良くない.
腐敗防止層を用意しておけば防げる.

抽象化の欠如
抽象化には漏れがあるということを前提としておいた方がよい.
作業する抽象化レイヤよりも下にあるレイヤの少なくとも1つを理解することで多少は防げるが、複雑なアーキテクチャになるにつれてそれは難しいこととなる.
こういった点をうまく適応度関数で守れる仕組みを用意した方が良いだろう.

ラスト10%の罠
顧客が望む残り10%は実現可能だが、かなり難しい.

コード再利用の乱用
コードの再利用は、レゴブロックを組み立てるというよりは、臓器移植に似ている.
無理に再利用できるようなコードを書くと、使いやすさが損なわれる.
マイクロサービスでは、ドメイン間のエンティティを分離することにあるため、ある程度の重複は許容する.
重複を促しているわけではないことに注意.

不適切なガバナンス
ガバナンスモデルは、単一の関心事に対して解決策を求める.
これでは今の世の中では不十分で、ゴルディロックスガバナンスモデルを利用した、単純・中間・複雑といった3つの技術スタックを選定しておき、各サービス要件によって技術スタック要件がを導けるようにしておくことができる.

リリース速度の欠如
生物の進化にはライフサイクルの短さは重要である.
それと同じでソフトウェアのライフサイクルも短い方が進化可能性を高めるうえで必要になる.

製品のカスタマイズ
顧客ごとにカスタマイズを請け負うと、それだけコストがかかるということを認識しておく.

レポート機能
アプリケーションとレポート機能はデータを共有する必要はないのに不必要に共有してしまう.
共有しないようにレポートではレポート用のデータを書き出すようなアーキテクチャにすべきである.

計画範囲
大幅な先行投資が必要とする技術には従ってはいけない.

所感

最近、自分が考えていることと同じような結論になっている箇所があって納得感があった.
ベンダーキングアンチパターンは腐敗防止層を入れる典型的な例で良さそう.
DDDをほぼ知らない状態なので、DDDを知るべきだという強い意識を持てる.
また現職では自社サービスを提供しているところであるため、より納得できる例が載っているのが面白い.

8章 進化的アーキテクチャの実践

進化的アーキテクチャを実践していくには、多くの関心事がある.
それは技術的なものだけでなく、ビジネス上の問題や組織・チームといった問題である.
組織・チームでいえばコミュニケーションコストがある.
機能横断型の方が調整の手間が少なくなりやすい.
ただ闇雲にすればいいというものではなく、Jeff Bezos氏が提唱した2枚のピザという概念がある.
大きな2枚のピザで賄える人数が1チームに最適だという話です.
チームの人が増えるとそれだけ各メンバー間のリンクが増えて管理するのが難しくなる.
実験するための基盤を組織に築くことも重要である.
外部からアイデアを取り入れる経路を作ったり、改善のサイクルを作ったり、イノベーションの時間を用意する必要がある.
全て進化的アーキテクチャにすればよいというものでもないことに注意.

所感

見出し通りの内容だったかと思う.
進化的なアーキテクチャであるかどうかは別として、それ以外でも有用そうな話はあった.
2枚のピザは割と有名な話だが、もう少し学術的な面で気になるところではある.
組織構造的な話には首を突っ込みたくないけど、そうは言ってられないしな.

まとめ

トータルとしては、1~5章までは軽く読む程度でいよい内容であったと思います.
細かい例が載っていたりしたが、要点さえ抑えておけば良さそうです.
7,8章をしっかり読めばこの本が言いたいことが載っているところなのかもしれない.
現職ではチャレンジが必要なフェーズであるので、そこで自分が議論するために必要な情報の1つを知れたという意味では良い本だったと思えます.
組織的な話は面倒そうなので必要な限り首突っ込みたくない.
とは言いつつ、何故か首を突ちっ込みがち...