進化的アーキテクチャ ―絶え間ない変化を支える

著者 : Neal Ford Rebecca Parsons Patrick Kua 島田浩二

• オライリージャパン (2018年8月18日発売)

作品紹介・あらすじ

2010年代のソフトウェア開発の全体像をまとめ、これから求められるアーキテクチャを探る！
Thoughtworks社のCTOをはじめとする執筆陣が、ビジネスの要請やソフトウェアエコシステムの変化に伴い、ソフトウェアシステムは変化していくなか、最初にどうアーキテクチャを考え、そのアーキテクチャをどう育てていくのかを鋭く考察する。マーティン・ファウラーによる「まえがき」を収録。

感想・レビュー・書評

[あかたさんの感想 · 2022年6月9日]

アジャイルやテスト駆動といったことの根本概念というものか。常に変動し続けるためのアーキテクチャということ。構築や考え方、実践方法を説いているが、いまいちピンとこない。現代のIT産業はすでにこう動いているからか？
155冊目読了。
#NealFord #RebeccaParsons

[へ〜たさんの感想 · 2019年12月8日]

ここ最近に読んだ技術概念書(コードを含まない概念論だけの本)の中では飛び抜けて秀逸。著者陣はマイクロサービスアーキに対しては懐疑的だが、しかしマイクロサービスアーキテクチャがもたらしたアーキテクチャのパラダイムシフトについては完全に理解し、言語化している。

[takeoverjpさんの感想 · 2024年4月9日]

面白かった。
訳のせいかもともとなのか、言い回しがわかりづらいところは多々あったが、
アーキテクチャを設計する上で学びになることもそれ異常に多かった。

以下、まとめ。

市場のニーズとともにシステムが提供するべき機能は変わり続け、技術のイノベーションとともにシステムが使うべき最適なソフトウェア開発エコシステムも変わり続ける。
このような状況で、システムを成長させるためには、さまざまな変化に適応しながら進化できるアーキテクチャが必要である。（「順応同化の精神」）

このような「進化的アーキテクチャ」を実現するためには、アーキテクチャ特性を評価可能にするべきである。
アーキテクチャ特性を評価可能にすることで、
・アーキテクチャ特性が経年劣化することを防げる
・アーキテクチャ特性に即した根拠が明確な決定を行える

アーキテクチャ特性を定量的に評価するための検証手段を、本書では「適応度関数」と呼んでいる。

「適応度関数」をデプロイメントパイプラインに組み込むことで自動的に逸脱を検出できることが最も望ましいが、
手動でもまずはあることが大切、というスタンス。

「適応度関数」は優先度とともに結果を覧化しておくことで、
アーキテクチャ上何が大切かがわかるようになる。

以下、読書メモ。

https://github.com/takeoverjp/booklog/blob/main/building_evolutionary_architectures.md

[Naruki Chigiraさんの感想 · 2024年2月18日]

本書は「適応度関数」が引用される場合に参考書籍として提示されることが多い。その定義を確認しておこうと本書を手に取ったが、適応度関数の定義も終始曖昧である。

> 進化的アーキテクチャが適応度関数によって誘導されると我々が言うときには、個別のアーキテクチャ上の選択を個々の適応度関数とシステム全体の適応度関数によって評価して、変化の影響を判断していくことを意味する。...全てのテストが適応度関数というわけではないものの、そのテストがアーキテクチャ上の関心事の完全性を証明するのに役立つ場合には、我々はそれを適応度関数とみなす。（2.1 適応度関数とは p.36）

直接的に適応度関数の定義を定める記述はないが、上記の引用によると、テストの中である特定の役割を持つものを適応度関数と呼んでいるように思える。

閾値をもつテストの存在意義は、元から継続的に対象を監視して閾値を超えないように運用をするといったところにあるはずだし、そこに動的平衡などの概念を加えたことによって新しい視点が生じているようには思えない。

既存の概念とソフトウェア開発の概念を組み合わせた結果、2つの概念がうまく組み合わさっていないものは他にもある。

> 物理学で定義されているように、量子とは相互作用に関与する物理的実体の最小量だ。アーキテクチャ量子とは、高度な機能的凝集を持つ、独立してデプロイ可能なコンポーネントだ。...モノリシックアーキテクチャでは、量子はアプリケーション全体となる。（4.2 アーキテクチャ量子と粒度 p.67）

物理的実体とは何かという話はあるが、それを抜きにしても「量子」はただのインパクトのあるワードとして使われており、全く違う意味になっている。

本書は、システム全体に寄与して継続的に動作し、事業や市場の状況に応じて追うべき指標が変わったら柔軟に変化に追従するテストの運用についての本として読むべきで、それ以外のセンセーショナルな表現は捨てても差し支えないだろうと感じた。うまく定義されていない概念によって、むしろ他者とシステムについて共通認識を持つ際の妨げになる可能性もある。

とはいえ、単に継続的にシステムの指標となるテストを適応度関数と呼ぶことが便利だからこそ引用も多くされるのだろうし、本書の外に出て具体的なテストの事例を多く集めて、自分が関わるシステムの継続的な成長に役立てることはとても有益だろうと感じた。

[やまずんさんの感想 · 2023年1月14日]

難しかった

[hmk404さんの感想 · 2023年1月2日]

マイクロサービスはなぜ必要か、その必要性を説明してくれる書籍、読み終えた時に感じたのはそういった感想。

すごくよかったわけではなく、マーチンファウラーのブログ記事などを参照させつつ、適応度関数という考え方に基づいて、Fearlessな形でアーキテクチャーをどう進化させるかを述べている。

[mさんの感想 · 2022年5月22日]

> 目標に向けて漸進

目標(重点アーキテクチャ特性)に向けて適応度関数(メトリクス、テストなど)を設定し、適応度関数によって誘導的に漸進する。(+適切な結合を保つ)
※ 締めの一節(引用文)からの私的拡大解釈、もしくはまとめ

[mさん · 2022/05/22]

> データベーストランザクションは強力な核力として振る舞い、量子を結び付ける

[mさん · 2022/05/22]

> 真の成功基準とは、24時間に詰め込める実験の数だ。 - トーマス・エジソン

[kaota01さんの感想 · 2021年11月30日]

抽象度が高いので評価が分かれそうだが、アーキテクチャの検討に直面している事情もあり、大いに示唆を与えられた(気がする)。
気がするだけか、ホントなのかはこれから次第か。何度か繰り返して読むのと、関連他書と組み合わせて読み返す、推敲するのが良さそうか。

抽象度の高さ、「適応度関数」の実態についてマイナス評価が多いようだが、それは概念として受け入れて、具体化は自分自身の解釈で形にすべきかと(それがアーキテクトの役割では？)

[catnapperさんの感想 · 2020年7月6日]

抽象度が高いのか、入ってこない部分が多い。
漸進的な変更を行えることの重要性と、それを実現するための要素などが書かれている。
気がついたら「適応度関数」という本書全体に関わるキーワードが繰り返し使われていて、要は何？と改めて読み返すことになった。結局はテストであり、そのビジネスで重要視されているアーキテクチャ特性を検証できるテストのことを指すのだと解釈した。
アーキテクチャスタイル毎の進化可能性について言及されていたことが一番収穫と感じた。マイクロサービスは向くところ向かないところがあるという感覚は読む前後で変わらないが、進化可能なアーキテクチャとしてより一般的に推奨されている感は感じられた。

[sou (08thse)さんの感想 · 2020年2月22日]

かなり抽象的ということもあり、個人的には難しめ。
ただ、変化に追従できるようにするためのアーキテクチャという、述べられている本質部分は共感できる部分は多いため、何度か読んでみたいとは思っています。