進化的アーキテクチャ

キーフレーズ

アーキテクチャ 開発者 適応度 アーキテクト サービス 進化 可能性 マイクロサービス 変更 関数 システム プロジェクト チーム 構築 プラクティス テスト 必要 PenultimateWidgets 結合 データベース アプリケーション コンポーネント ソフトウェア フレームワーク 多く ソフトウェアアーキテクチャ 機能 デブロイメントパイプライン インフラストラクチャ コード ビジネス 継続的 https 可能 全て ソフトウェア開発 リファクタリング 開発 データ できる 技術 バージョン サイクルタイム スケーラビリティ プラグイン モノリス .com DevOps ツール 問題 再利用 PenuItimateWidgets ケーススタディ ホリスティック ドメイン デブロイ 企業 コンテキスト Mediator 設計 変化 DBA モジュール 示す アンチパターン 新しい レイヤ トランザクション 重要 サポート http:// 漸進 する 継続的インテグレーション 場合 定義 実行 運用 特性 マイグレーション 最終的 影響 統合 環境 次元 依存 スキーマ 自動化 方法 ワークフロー ライプラリ アーキテクチャパターン アーキテク 一般的 アーキ エコシステム デリバリー オープンソース

目次ページ

52 ー 3 章漸進的な変更を支える技術 3 5 目標の衝突 アジャイルソフトウェア開発プロセスは、問題を早期に検出できるほど修正に要す る労力が少なくて済むということを、我々に教えてくれた。ソフトウェアアーキテク チャの全ての次元を広範囲に考慮することの副次的効果の 1 つには、次元間で衝突 する目標を早期に特定できることがある。例えば、開発者は新しい機能をサポートす るためにもっと積極的な変更ペースをサポートしたいと考える可能性がある。コード を頻繁に変更していくということは、データベーススキーマも頻繁に変更していくこ とを意味する。しかし、データベース管理者はデータウェアハウスを構築しているた め、安定性をより重視する。したがって、 2 つの進化の目標は、技術アーキテクチャ とデータアーキテクチャの間で衝突することになる。 明らかなことは、根本的なビジネスに影響を与える無数の要因を考慮したうえで、 何らかの妥協をする必要があるということだ。アーキテクチャの次元をアーキテク チャの関心事の一部を特定するテクニックとして使うこと ( あわせて適応度関数をそ の評価に使うこと ) は、同一条件でそれらを比較することを可能にし、それによって 優先順位付けをよりはっきりと行えるようになる。 目標が衝突することは避けられない。しかし、そうした衝突を早期に発見して定量 化することによって、アーキテクトはより明確な意思決定を行い、より明確に定義さ れた目標と原則を作成できるようになる。 3. 北 6 ケーススタディ : PenuItimateWidgets の請求書発 行サービスに適応度関数を追加する 本書で例示に使用している架空の企業 Penultimate 、 Vidgets は、アーキテクチャに 請求書発行を処理するサービスを含んでいる。請求書発行サービスのチームは、古い ライプラリややり方を置き換えたいと考えている。しかし、そうした変更が他のチー ムの請求書サービスを統合する能力に影響を与えないようにしたいとも考えている。 請求書発行サーピスチームは以下のニーズを特定した。 スケーラビリティ パフォーマンスは Penul ⅱ mate 、 Vidgets の大きな関心事ではない。しかし、 っかの再販業者に向けた請求の詳細を取り扱っているため、請求書発行サー はサービスレベル合意を維持する必要がある。 いく ビス

3. ] 他のサービスとの統合 構成要素 PenultimateWidgets 工コシステムのいくつかのサービスが請求書発行サー 53 ビス を使用している。チームは内部の変更を行いつつ、統合点が壊れないようにした いと考えている。 セキュリティ 請求書発行は金銭のやり取りを意味する。そのため、 れる事項だ。 監査可能性 セキュリティは常に懸念さ 州の規制によっては、独立した会計士によって課税法の変更を検証する必要がある。 請求書発行サービスチームは継続的インテグレーションサーバーを使用しており、 チームは最近、実行環境のプロビジョニングをオンデマンドで行うようアップグレー ドした。進化的アーキテクチャの適応度関数を実装するには、図 3 - 8 に示すように、 継続的インテグレーションサーバーをデブロイメントパイプラインに置き換え、実行 PenuItimateWidgets のデブロイバイプラインは 6 つのステージで構成されてい の段階的なステージを作成できるようにする必要がある。 る。 ステーシ 1 0 の複製 最初のステージでは、元の CI サーバーを複製し、 テストを実行する。 コンテナ化とデブロイ ステーシ 2 そこでユニットテストと機能 開発者は第 2 ステージを使って、サービス用にコンテナをビルドし、動的に作成 されたテスト環境にコンテナをデブロイすることで、より深いレベルのテストを 行えるようにする。 第 3 ステージでは、自動スケーラビリティテストやセキュリティ侵入テストと アトミックな適応度関数 ステーシ 3 いが、後のステージで特定のコードを絞り込むのに役立つ。 クスツールを実行したりもする。このツールは何かしらの決定を行うわけではな 関連して、開発者が変更した特定のパッケージ内の任意のコードに対してメトリ いったアトミックな適応度関数が実行される。このステージでは、監査可能性に

54 3 章 漸進的な変更を支える技術 0 9 9 アトミックな コンテナ化と デブロイ 適応度関数 0 の複製 01001001010101 01010101010101 00101010010010 00100100010001 セキュリティ レビュー 本番環境へ デブロイ ホリスティックな 適応度関数 監査 0 9 図 3 - 8 PenultimateWidgets のデブロイメントパイプライン ホリスティックな適応度関数 ステーシ 4 第 4 ステージは、ホリスティックな適応度関数の実行に焦点を当てる。ホリス ティックな適応度関数には、統合点を保護する契約に対するテストや、さらなる スケーラビリティテストなどが含まれる。 ステージ 5a ーセキュリティレビュー ( 手動 ) このステージには、組織内の特定のセキュリティグループによって手動で行われ るステージが含まれる。これには、コードベースでのセキュリティ上の脆弱性の レビューや監査、評価などがある。デブロイメントパイプラインには、セキュリ ティスペシャリストによる要求によって生じる、手動で行うステージを定義する