#進化的アーキテクチャ

1章　ソフトウェアアーキテクチャ
2章　適応度関数
3章　漸進的な変更を支える技術
4章　アーキテクチャ上の結合
5章　進化的データ
6章　進化可能なアーキテクチャの構築
7章　進化的アーキテクチャの落とし穴とアンチパターン
8章　進化的アーキテクチャの実践

『UNIXという考え方―その設計思想と哲学』、worse is betterなどを思い出した。

サービスの分割の塩梅という意味でのmicroserviceならぬmacroservice

モノリシックからマイクロサービスへ。あるいは、サービスベースアーキテクチャを考える。

2章　適応度関数

アーキテクチャの適応度関数は、あるアーキテクチャ特性がどの程度満たされているかを評価する客観的な指標を与える。

アーキテクトは適応度関数を定義し、何がより良いかを説明するとともに、目標が達成されたかの計測に役立てる。ソフトウェアにおいて適応度関数がチェックするのは、開発者がアーキテクチャ上の重要な特性を維持できているかだ。

パフォーマンス要件は、適応度関数を有効に活用する。全てのサービス呼び出しが100ms以内に応答しなければならないという要件があるとする。このときには、サービス要求に対する応答時間を計測して100msを超えていたら失敗するというテスト（すなわち適応度関数）を実装できる。

下記の記事を読むまで、適応度関数とはリグレッションテストのことだと思っていたが、それだけではなく非機能試験の要素も含むことが分かった。

ミイラ取りがミイラになりかねない

アーキテクトを不可逆的な判断へと導く長期の計画サイクルに用心し、選択肢を開いたままにする方法を見つけよう。大きな問題を小さな問題に分解し、アーキテクチャ上の選択と開発インフラストラクチャ両方の実現可能性を早期にテストしよう。アーキテクトは、その技術が実際に解決しようとしている問題に実際に適しているかどうかをエンドユーザーからのフィードバックを通じて検証する前に、ソフトウェア構築前の大幅な先行投資（大規模なライセンスやサポート契約など）を必要とする技術には従ってはならない。

「技術的負債」との向き合い方

特にPMF前のプロダクト開発では、ドメインの複雑性に真正面から立ち向かうことになります。僕たちのチームも、まさにいまその真っ只中にいるところです。不完全な理解であってもなるべく早く形にし、ユーザからフィードバックをもらうことが、プロダクトを進化させていく上での生命線です。
一方で、品質低下も見逃すことはできませんが、これはエンジニアの腕の見せどころです。どんなに変化の激しい開発であっても、未来のユーザ価値を損ねないよう、プロダクトの進化を支えるのもまた僕たちの仕事です。

学び
・北極星とは何か？
・現状維持ではいけない
・対立するステークホルダー間での落としどころとしてのエラーバジェット
・障害を意図的に起こすことで障害を防ぐ
・適応度関数やっぱりわからない

適合度関数によってアーキテクチャの目標満足性を検証する
進化的アーキテクチャは，多次元にわたる第１原則として，方向性を持った漸進的変化を可能にします。
-> このような進化をサポートする上で，適合度関数は，設定されたアーキテクチャ目標をシステムがいかに満足しているかを自動的に評価する方法を見出す一助となる，と両氏は考えている。