124 ー 6 章進化可能なアーキテクチャの構築 関数として考え始めるべきだ。これには、以前は場当たり的に考えていたことも含ま れる。例えば、多くのアーキテクチャにはスケーラビリティに関するサービスレベル 合意 (SLA) があるだろうし、それに対応するテストもあるはすだ。同様に、セキュ リティ要件に関する規則もあるだろうし、それに付随する検証の仕組みもあるはす だ。アーキテクトはこれらを別々のカテゴリとして捉えてしまうことが多い。しか し、アーキテクチャにおける何らかの特徴を検証するという点では、どちらも意図す るところは同じだ。アーキテクチャにおける全ての検証を適応度関数として捉えるこ とで、自動化をはじめとする有益な相互作用を用意する際に、より一貫した取り扱い が可能になるのだ。 リファクタリングと再構築 開発者は、クールに聞こえる用語を選出して彼らの共通語彙とすることがよ くある。リファクタリングなどがそれだ。 Martin Fowler によって定義されて リファクタリングは既存のコードを外部からの振る舞いを変え いるように、 ることなしに再構築するプロセスだ。多くの開発者にとって、リファクタリン グは変更と同義になっている。しかし、そこには重要な違いがある。 チームがアーキテクチャをリファクタリングすることは非常にまれだ。むし ろ、彼らはそれを再構築し、構造と振る舞いの両方に実質的な変化をもたらす。 アーキテクチャパターンは、 1 つにはアプリケーションの主要なアーキテク チャ特性を確かめるために存在する。パターンを切り替えることは、必然的に 優先度を切り替えることを伴う。よってこれはリファクタリングではない。例 えば、アーキテクトはスケーラビリティのために EDA を選択していたとする。 もしチームが異なるアーキテクチャパターンに切り替えたなら、同じレベルの スケーラビリティはサポートされなくなる可能性があるだろう。 6.34 COTS との関わり合い 多くの組織では、開発者はエコシステムの構成要素全てを所有しているわけではな い。大企業では、商用オフザシェルフ (Commercialoff-the-sheIf: COTS) やパッ ケージソフトウェアが普及している。そのことは、進化可能なシステムを構築する

116 ー 5 章進化的データ からだ。 残し、それらを交差テープルを介して相互に重ね合わせていっているだけでしかない くのデータが必要になる。 り多くのコンテキスト ( 元のページやワークフロー状態など ) が必要となり、より多 変更することを意味する。新しいルーティングメカニズムを実装するべージでは、よ ( 社内フレームワークを使って ) これまで行ってきたページ間のルーティング方法を ザーにナビゲーションのパンくすリストを提供しようと決めた。これを行うことは、 PenultimateWidgets はページ間の新しいルーティングスキーマを実装し、ユー ティングを進化させる 5.3 ケーススタディ : PenuItimateWidgets のルー を過去と結びつけ、それはリファクタリングを難しくする。 スキーマのリファクタリングや古いデータの削除を拒むことは、アーキテクチャ は参照用には利用可能にしつつも、進化的な開発の主流からは外すようにしよう。 うか。本当の価値があるデータを見定めて、それを保持しよう。そして、古いデータ データを永久に保持し続けることだろうか。それとも、進化的な変更を作る能力だろ ついて率直な会話をする必要がある。組織における価値を表しているのは、レガシー アーキテクト、 DBA 、ビジネス担当者は、何が組織における価値を表しているかに レガシーなスキーマとデータには価値があるが、進化する能力への重しにもなる。 るのではなく、これらの問題を早期に解決することを勧める。 いくべきだ。我々は、これらの問題を永久に処理する複雑で継続的な仕組みを構築す グを必要とし、 DBA はデータの品質を基礎とするために必要な行動を何でもやって 発者がデータをうまく進化できるようにしてほしい。不十分な構造はリファクタリン 進化的アーキテクチャを構築しようとする前に、スキーマと品質の両方の観点で開 によって物事をうまく行う際に複雑な回避策を強いることになる。 のあらゆる断片を保持しようとすることは、アーキテクチャを過去と結び付け、それ 引き起こしたり、最悪の場合はデータ自身をゴミにしてしまう。多くの点で、データ 世代のソフトウェアを生き残るが、そこで残ったデータのねじれは、一貫性のなさを レガシーデータの品質は別の大きな問題も表している。しばしば、データは多くの

108 ー 図 5 - 2 図 5 - 3 5 章 進化的データ 移行用コードを置く データをマイグレートし、 新しい変更をデブロイし、 開始 リファクタリング を実施する 拡張 (Expand) 移行 移行期間 ( 新旧の スキーマを共存 ) 旧スキーマと 移行用コードを 削除する 終了 リファクタリング 完了 収縮 (Contract) ァータベースリファクタリングにおける expand / cont 「 act パター Custome 「 CustomerlD Name 開始 name = 開始状態 "Pramod SadaIage" Customer CustomerID Name 日 rstName stNa me Synchro nizeCustomerName { event = update い ns t } 拡張状態 LastName FirstName Custome rl D Custom er 収縮後状態 拡張 (Expand) name = "Pramod Sadalage" firstname = "Pramod' lastname = "Sadalage" lastname = "Sadalage" firstname= "Pramod" 収縮 (contract) expand/contract リファクタリングの 3 つの状態

5. ] アプリケーシン 図 5 - 1 データベースを統合点として使用する 進化的なデータベース設計 アプリケーション い 07 アプリケーション 図 5 - 1 では、 3 つのアプリケーションが同じリレーショナルデータベースを共有し ている。多くのプロジェクトでは、高い頻度でこの統合スタイルがデフォルトになる。 全てのプロジェクトがガバナンスのために同じリレーショナルデータベースを使用す るのであれば、プロジェクトをまたいでデータを共有しない理由があるだろうか。し かし、データベースを統合点として使用すると、アーキテクトは全ての共有プロジェ クトを横断するデータベーススキーマが化石化してしまうことをすぐに発見する。 結合しているアプリケーションの 1 つが、スキーマの変更によって進化しなくては ならない場合はどうだろうか。アプリケーション A がスキーマに変更を加えると、 れによって残り 2 つのアプリケーションが破損する可能性がある。『データベース・ リファクタリング』で説明したように、幸いにも expand / co 猷 ract バターンと呼ばれ る一般的に利用されているリファクタリングパターンを使用して、この種の結合をほ どくことができる。多くのデータベースリファクタリング手法は、図 5 - 2 に示すよう リファクタリングに移行フェーズを設けることで、タイミング問題を回避する。 このパターンでは、開発者は移行開始時と終了時の 2 つの状態を持ち、移行中は その古い状態と新しい状態の両方を維持する。移行状態は後方互換性の維持を可能に し、企業内の他のシステムが変更に追いつくのに十分な時間も与える。組織によって は、移行状態が数日から数か月にわたって続く可能性もあるからだ。

4.2 アーキテクチャ量子と粒度一 63 ジネスの一部が強く結びついている可能性がある場合に、アプリケーションを小さな アーキテクチャ上のコンポーネントに分割することは望ましくないことがある。 図 4 - 2 にこれらの用語の関係をまとめる。 モノリシックな Listing 我々は数年間、自動車のオークションを中心としたプロジェクトに従事して きた。驚くべきことではないが、システムにおける巨大なクラスの 1 つには Listing クラスがあった。それは怪物へと成長していた。 Listing クラスが調整 問題を引き起こしていたため、開発者は巨大なクラスを分解する方法を見つけ ようと、いくつかの技術的なリファクタリング作業に取り掛かった。そして、 最終的には主要な部品の 1 つである Vendo てを独自のクラスに分割するための スキーマが生み出された。技術的なリファクタリングがうまくいった一方で、 開発者とビジネスアナリストとの間では問題が発生した。開発者は Vendor への 変更のことばかり話し続けていた。しかし、それは彼らの世界では独立した工 ンティティではなかった。開発者は、 DDD で Eric Evans がプロジェクトのユ ビキタス言語と呼んだものに違反していた。ュビキタス言語では、チームにお ける全ての用語が確実に同じものを意味する。機能の分割は開発者にとって多 少便利なことがあったものの、ビジネスプロセスを定義する意味的な結合が侵 害されたため、仕事はより一層難しくなってしまった。 最終的に、我々は Listing クラスをリファクタリングせすに、 1 つの巨大な 工ンティテイへと戻した。ソフトウェアプロジェクトがそれを中心に回ってい たからだ。そして、我々は Listing を異なる方法で処理することで調整問題を 解決した。積極的な統合を促進するため、 Listing に変更があると、継続的イ ンテクレーションサーバーが関心のあるチームへメッセージを自動で生成する ようにしたのだ。このようにして、我々は調整問題を、アーキテクチャの構造 としてではなく、開発プラクティスの実践によって解決した。

216 ー 索引 ュビキタス言語 . リファクタリング アップデート .. ライプラリ .. 予測可能… 予算… ら行 … 189 ... 199 … 59 , 64 ... 148 … 116 , 124 , 187 量子… リレーショナルデータベース .. ルーティング .. レイヤ化アーキテクチャ .. レジュメ駆動開発 .. レポート機能… 論理ビュー … 60 , 64 , 99 , 201 … 106 … 117 , 153 … 7 , 68 … 165 … 173 .. 12

5 章 進化的データ Pramod SadaIage による寄稿 リレーショナルデータベースを始めとする各種データストアは、今日のソフトウェ アプロジェクトに遍在し、アーキテクチャ上の結合以上に問題となることの多い結合 を形作る。データは進化可能なアーキテクチャを作る際に考慮すべき重要な次元だ。 進化的データベース設計の側面全てをカバーすることは、本書の範囲を超えている。 幸いなことに、我々の同僚である PramodSadalage は、 ScottAmbler とともに「進 化的データベース設計」という副題がついた書籍『データベース・リファクタリング』 ( ピアソン・エデュケーション ) を執筆した。本書では進化的アーキテクチャに影 響するデータベース設計について一部だけをカバーする。残りはぜひ『データベー ス・リファクタリング』を読んでいただきたい。 本書で DBA について触れるときに想定しているのは次のような人物だ。それは、 データ構造を設計し、アプリケーション内でデータにアクセスしたり使用したりする コードを書き、データベースで実行されるコードを書き、データベースのメンテナン スやパフォーマンス調整を行い、そして障害発生時の適切なバックアップ手順や復旧 手順も保証する人物だ。 DBA と開発者は、アプリケーションを構築する中心的存在 であることが多く、密接に連携する必要がある。 5 ゴ進化的なデータベース設計 データベースにおける進化的な設計は、時間とともに要件が変化する中で、開発者 がデータベースの構造を構築でき、進化させられるときに現れる。データベースス キーマとは、クラス階層と同様、物事を抽象化したものだ。根底にある現実世界が変 化したなら、それらの変化は、開発者と DBA が構築している抽象にも反映されなけ ればならない。そうでないと、その抽象は徐々に現実世界と同期されなくなる。

50 ー 3 章漸進的な変更を支える技術 t て y プロックを実行するかどうかを決定する 開発者は Scien ⅱ st を設定し、実験をどう実行するかを決定する。例えば、マー ジ機能の更新を目標としたこのケースでは、ランダムユーザーの 1 % に対して新 しいマージ機能が試された。どちらが実行された場合でも、 Scientist は use プ ロックの結果を常に返し、結果に相違があっても、呼び出し元は常に既存の機能 の結果を受け取ることが保証されている。 use プロックと try プロックを実行する順序をランダム化する こうすることで、 scien ⅱ st は未知の依存関係によってバグを誤って隠してしまう ことを防ぐ。場合によっては、順番やその他の偶発的な要因が誤判定を誘発する 可能性があるからだ。 Scientist はプロックの実行順序をランダム化することで、 そうした欠陥を少なくする。 全ての振る舞いの時間を計測する Scientist の仕事の一部は A / B パフォーマンステストだ。したがって、パフォー マンスの監視が組み込まれている。実際、開発者はフレームワークを部分的に使 うことができる。例えば、実験することなしに計測のためだけに使うことができ るということだ try の使用結果と use の使用結果を比較する 目標は既存の振る舞いをリファクタリングすることだ。そのため、 Scientist はそ れぞれの呼び出し結果を比較、記録して、相違が存在するかどうかを確認する。 t て y プロック内で発生した例外を潰す ( ただしログは記録する ) 新しいコードが予期しない例外を投げる可能性は常にある。しかし、開発者は工 ンドユーザーにこれらのエラーを見せたくはない。そのため、 Scientist はエンド ューザーへそうした例外を見せなくする ( ただし、開発者の分析用にログの記録 は行う ) 。 この全ての情報を公開する scien ⅱ st は全てのデータを様々な形式で利用できるようにする。 マージ機能のリファクタリングのケースでは、 GitHub の開発者は、例 3 - 3 に示す ように、新しい実装 (create_merge_commit_rugged) を呼び出すテストを行った。

8.2 チーム結合特性い 87 やフレームワークの外側でコードを書いたりテストしたりすることは容易だろうか ? 新しいライプラリやフレームワークは、開発のループを遅くさせるような新しいラン タイム設定を必要とするだろうか ? 新しいライプラリやフレームワークの選択に加えて、コードレビューは新しく変更 されたコードが将来の変更をどの程度うまくサポートするかを検討するのに適した場 所だ。もしシステムの別の場所が突然に他の外部統合点を使うことになり、その統合 点が変更されることになると、どれくらい多くの箇所を更新する必要があるだろう か。もちろん、開発者は過剰性能や時期尚早な変更のための余分の複雑さや抽象の追 加に注意する必要がある。『リファクタリング』 ( オーム社 ) 囮にはこれに関連する 以下のアドバイスがある。 3 度目になったらリファクタリング開始 最初は、単純に作業を行う。 2 度目に以前と似たようなことをしていると気づい た場合には、重複や無駄を意識しつつも、とにかく作業を続けてかまわない。そ して 3 度目に同じようなことをしていると気づいたならば、そこでリファクタ リングをする。 多くのチームは、新しい機能を提供することによって最もよく突き動かされ、見返 りを与えられる。コード品質と進化可能性の側面は、チームにとってそれを優先され る場合にのみ考慮される。進化的アーキテクチャを気に掛けるアーキテクトは、チー ムが進化可能性を助ける設計判断を優先したり、それを促進する方法を見つけたりし ているかどうかといった、チームの行動について注意を払う必要がある。 8 念 2 実験の文化 進化を成功させるには、実験が必要だ。しかし、計画に忙しすぎるために実験に失 敗する企業も存在する。実験を成功させるとは、小さいアイデア ( 技術的側面とプロ ダクトの側面の両方から ) を試す習慣的な小さなアクティビティを実行し、うまく 真の成功基準とは、 24 時間に詰め込める実験の数だ。 行った実験を既存のシステムへと統合することである。 トーマス ・、エジソン

目冫欠 参考文献… 索引 .. コラム目次 PenultimateWidgets の紹介と、彼らが逆コンウェイ戦略を取る機会 . PenultimateWidgets とエンタープライズアーキテクチャスプレッドシート… 30 継続的インテグレーション vs デブロイメントパイプライン .. PenultimateWidgets のデブロイメントパイプライン .. 本番環境における QA... ドメイン駆動設計の境界づけられたコンテキスト .. モノリシックな Listing … 「無共有」と適切な結合… DBA 、べンダー、ツールチェイン . リファクタリングと再構築 .. スノーフレークの危険性 .. インターネットを壊した 11 行のコード .. IBM のサンフランシスコプロジェクト . 強制的な分離… DevOps の自動化による新しいリソースの発見… Amazon の「 2 枚のピザ」チーム .. インフラストラクチャはアーキテクチャに影響を与える . ケーススタディ : オープンソースライプラリの合法性 .. ー XiX … 209 … 212 … 16 … 41 … 43 … 45 … 63 … 92 … 112 … 124 … 137 … 147 … 161 … 168 … 179 … 182 ... 191 … 195