まとめ

• 進化的アーキテクチャは、具体的なアーキテクチャを決める手法ではなく、継続的に変更可能なアーキテクチャを支援するための手法
• 漸進的な変更・適応度関数・適切な結合から構成される
• 適応度関数は、要件が担保できているかを確認する仕組みのことで、自動テストや手動テスト・監査・セキュリティレビューがある
• 漸進的な変更は、開発とデプロイメントの2つの側面からなり、「テストがしやすいアーキテクチャにすること」「継続的デリバリーができるデプロイメントパイプラインを定義すること」が大事
• オーバーヘッドが少なく最大の利益をもらたす適切な結合があるアーキテクチャを選択しましょう

[*** 目次]

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

[*** メモ]

• 適応度関数

  • 定量的な指標
  • ソフトウェアでは実装できない場合もあるがアーキテクチャ上の検証を適応度関数として明らかにすることは依然として有効

• アーキテクチャの分類

  • モノリス（3層レイヤ化モノリス等を含む）
  • イベント駆動アーキテクチャ
  • SOA
  • マイクロサービス
  • サーバレス

• サービス境界分割の手法

  • ビジネス機能グループ
  • 既存のビジネスコミュニケーション階層を反映する。コンウェイの法則に従う。
  • トランザクション境界
  • トランザクションは最も分離しにくい要素である。
  • デプロイメント目標
  • デプロイ頻度が異なる箇所を境界とする。

• コンウェイの法則／逆コンウェイ戦略

  • システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に倣った構造を持つ設計を生み出す。

• 結合よりも重複

  • 疎結合のために重複を許容すること

マイクロサービスは無共有アーキテクチャを形成する。その目標は、できるだけ結合を減らすことだ。一般的に、結合よりも重複の方が望ましい。

ツールがあまりにもコードの再利用を容易にしてしまったせいで、現代の開発者は、たやすく結合できてしまう環境の中で適切な結合を行うことに悪戦苦闘している。

例えば、 CatalogCheckout サービスと ShipToCustomer サービスの両方が Item という概念を持つ。両方のチームが同じ名前と同じプロパティを持つので、開発者はサービスをまたいでそれを再利用しようと試みる。それが時間や労力の節約につながると考えるからだ。けれど、それは労力を増やす結果となる。なぜなら、コンポーネントを共有する全てのチームが変更を伝搬しなければならなくなるからだ。一方、コンポーネントを結合せずに各サービスにItem があり、必要な情報だけをCatalogCheckout から ShipToCustomer に渡す場合は、それらは独立して変更することが可能だ。

開発者が再利用可能なコードを作成する場合、開発者は最終的にコードを使用する無数の方法に対応するための機能を追加する必要がある。その将来の保証全ては、開発者がコードを単一の目的のために使用することをより難しくする

• 腐敗防止層を設ける
  • レイヤー間に将来的な変更可能性を残しておく
• デプロイに関するプラクティス
  • 継続的デプロイは開発側の都合であって、ユーザは頻繁な小規模改修を望んでいない
  • 機能トグル