レイヤー図によるアプリケーション構造の安定化
チームでコードを少しずつ開発する場合、コードは頻繁に変更および拡張されます。これらの変更によって依存関係がますます複雑になる場合があり、このために時間の経過と共にコードの変更がより難しくなります。チームでレイヤー図を使用して、アプリケーションのコンポーネント間の依存関係を設計し、検証することでこの問題を回避できます。
レイヤー図を使用することで、チームはアプリケーションの主要なパートと、それらの間の依存関係を、各パート部分の動作とそれらがやり取りするしくみの詳細情報を除いて表示できます。
また、チームでレイヤー図を使用して、コードがアーキテクチャに準拠していることを確認することもできます。Visual Studio でレイヤー図を描画するときに、クラスのグループをコードから各レイヤーに割り当て、矢印を使用して依存関係を指定できます。その後で、Visual Studio を使用して、コード内の依存関係が、レイヤー図に描画した矢印に実際に従っていることを検証できます。
レイヤー図を検証するチェックイン ポリシーを定義し、チームのビルドで継続的にそのチェックイン ポリシーを使用することで、チームが今後の変更が常にアーキテクチャに準拠していることを確認できます。
レイヤー検証の導入
このセクションで示す手順に従うことで、チームはレイヤー検証の使用を開始できます。
新しいコードを記述しているときにレイヤー検証を使用するには
アプリケーションのコードを最初に記述するのとほぼ同時に、レイヤー図を描画し、主要なコンポーネントとそれらの間の依存関係を表します。おそらく、アプリケーションの開発が進むにつれ、プロジェクトの進行中に図を変更することになります。
詳細については、「レイヤー図: リファレンス」を参照してください。
名前空間またはクラスを作成したら、それらをレイヤーに割り当てます。
コードをチェックインする前に、レイヤー図を右クリックし、[アーキテクチャの検証] をクリックします。
チェックイン手順および通常のビルド手順にレイヤー検証を追加します。
詳細については、「レイヤー図を使用したコードの検証」を参照してください。
既存のアプリケーションを更新するときにレイヤー検証を導入するには
アーキテクチャ エクスプローラーおよび有向グラフを使用してアプリケーションを調査し、その構造をある程度理解します。理解を深めるにあたって以下の手順が役立ちます。
主要なコンポーネントとそれらの適切な依存関係を示します。詳細については、「コードからのレイヤー図の作成」を参照してください。
アーキテクチャ エクスプローラーまたはソリューション エクスプローラーから要素をドラッグして、要素をレイヤーに割り当てます。
レイヤー図を右クリックし、[アーキテクチャの検証] をクリックします。
エラー レポートを調べて、次の手法を使用してエラーを修正します。
レイヤー図を修正します。既存のコードをより正確に表すようにレイヤー図を改善するか、コード要素を異なるレイヤーに再割り当てします。
コードを修正します。レイヤー図が既存のコードよりも良い設計を表していると思う場合は、レイヤー図に合わせてコードを更新できます。
詳細については、このトピックで後述する「既存のコードのリファクタリングによるレイヤー図への準拠」を参照してください。
エラーが報告されなくなるまで、ここまでの手順を繰り返します。
チェックイン手順および通常のビルド手順にレイヤー検証を追加します。
詳細については、「レイヤー図を使用したコードの検証」を参照してください。
.gif "Ff398054.collapse_all(ja-jp,VS.110).gif")
既存のコードのリファクタリングによるレイヤー図への準拠
チームが既存のアプリケーションでの作業を開始するときに、アプリケーションの構造が本来の構造よりも複雑であることに気付く場合があります。レイヤー図を描画して、要素をレイヤーに割り当てようとしたときに、このような状況に気付きます。チームで、要素をレイヤーに割り当てる際に、論理的には不要なレイヤーや依存関係を導入したり、レイヤーをスキップする依存関係またはループを形成する依存関係を導入したりしなければ、検証できない場合があります。このような欠点により、コードの理解および変更が困難になり、その動作がユーザーにとって一貫性がないように見える場合があります。
チームでは、コードをリファクタリングしてその設計を改善することで、コードの作業をしやすくすることができます。チームで、コードをリファクタリングして設計を改善することを決定する場合は、次の点を考慮してください。
リファクタリングの変更を他の変更から切り離しておきます。リファクタリングの変更に、ユーザー ストーリーの重要な変更が含まれないようにします。
提案された各変更を製品バックログに追加し、変更の説明と予想される利点を含めます。
[!メモ]
実装およびテストに数時間しかかからないリファクタリングの変更は、バグとして処理できます。大規模なリファクタリングの変更は、製品バックログに追加して、バックログ内の他の項目と共に評価し、優先順位を付ける必要があります。
リファクタリングを始める前に、作業対象の領域の機能が変更されていないことを確認するテストを作成します。
レイヤー モデルの更新
最初の 1 ～ 2 スプリントの後に、レイヤー図が安定したままである必要があります。通常、レイヤー検証エラーは、レイヤー モデルのエラーではなくコードのエラーと見なされます。
レイヤー モデルを更新する必要がある場合は、提案された変更をチームで確認します。
レイヤー モデルのほとんどの変更は、次のカテゴリに分類されます。
拡張: コードにコンポーネントを追加したため、それに応じてレイヤーを追加する必要が生じます。
詳細化: 現時点では、多数のコード要素が 1 つのレイヤーに割り当てられています。1 つのレイヤーをより小さいレイヤーに分割してレイヤー検証の効率を向上します。
リファクタリング: 既存のコードの依存関係構造を改善します。既存の構造が現在のレイヤー図に反映されています。したがって、レイヤー図とコードを同時に改善します。
関連トピック
レイヤー図: リファレンス
レイヤー図を描画する方法です。レイヤー図: ガイドライン
レイヤー図で表される内容、および図の使用方法です。コードからのレイヤー図の作成
既存のコードの構造を反映するレイヤー図を作成します。レイヤー図を使用したコードの検証
チェックインおよび継続的なビルドにレイヤー検証を組み込みます。