原則6 可変機能と不変事実を分離
データの構造を安定させる
ITアーキテクチャーを考える上で最大の難問は、時間の経過とともに機能要求が変化すること。採用するアーキテクチャーは機能要求を満たす必要があるので、当然、機能要求を前提にしてアーキテクチャーを考えることになる。しかし、その前提となる機能要求が変化してしまう。だから、前提（機能要求）が変化するという想定に基づいて、ソフトウエアアーキテクチャーを定義しなければいけない。
機能要求の変化を想定していない場合は、相次ぐ改修でコードやデータの依存関係が統制しきれなくなり、設計当初のアーキテクチャーが崩れていく。その結果、ソースコードやデータマートが、あたかも坂道を転げ落ちる雪だるまのように肥大化してしまう。ひとたびそうした状態に陥ると、遠からずシステムの寿命が尽きることになってしまう。保守性が悪化して改修時の影響範囲調査が困難を極め、たった1行の変更に何カ月もかかるようになるからだ。
変化頻度に着目して層を分ける
では、前提が変化するという想定の基に、どのようにアーキテクチャーを定義するのか。企業システムでは本質的に、可変の機能（アプリケーション）の実現と、不変の事実（データ）の管理の両方が求められている。ここにヒントがある。両者を分離することによって、困難な問題をやさしい問題の集合へと変えられるのだ。そしてこの、可変の機能と不変の事実データの分離が、ITアーキテクトの六つめの行動原則となる。
機能要求の変化を前提にすると、機能視点では「ある時間に最適な機能分割が、未来永劫に適切であり続けるとは考えない」ことが求められる。また、データ視点では、「機能要求の変化に対する高い耐性を持つ、高い安定度を備えるデータ構造にする」ことが求められる。
さまざまな機能から共有されるデータの構造を安定させるには、変化頻度に着目して層（レイヤー）に分け、変化するアプリ機能と不変の事実であるデータを分離すればよい。安定度の高い事実の管理を下層に、より変化頻度が高い機能の実現を上層に配置する（図7）。同時に、上位層が下位層に依存する順方向への依存のみとして、その逆の依存関係は絶対に生じさせないようにする。さらに、層内を互いに独立したコンポーネントに部屋割りする。こうすることで、機能要求に変化が生じたとしても、その変化の影響をコンポーネント内に閉じ込められる。
テーブルを細分化し責務を不変に
水平方向へのレイヤー分割と、垂直方向へのコンポーネント分割。この縦横の分割によって、機能独立およびデータ独立を実現する鍵が、可変の機能と不変の事実の分離である。つまり、いかなる機能要求にも左右されないデータモデルが出発点となる。
大切なのは、機能の実現という関心事を完全に振り払い、事実の管理だけを目的に完全に正規化すること。正規化するほどテーブルが細分化され、個々のテーブルが安定する。
そしてテーブルの責務が不変になれば、データモデルの差分を追加することで、データモデルを拡張できるようになる。つまり、新たな事実の管理が必要になった場合、既存のテーブルを一切変更することなく、新たなテーブルを追加するだけで対応できる。これなら、バージョンアップで問題が起こっても即座に元の状態に戻せるので、可変の機能に対応しながら安定的に継続稼働させることが可能になる。
