ガイドライン: レイヤリング
トピック
レイヤリングはシステム ソフトウェアをいくつかの部分に論理的に区分する働きをします。その際、レイヤ間の関係を構成する方法には、ある種のルールが適用されます。レイヤリングによって、サブシステム間の依存関係が抑制されます。その結果、システム間の結びつきが緩やかになり、保守が容易になります。
サブシステムをグループ化する基準にはいくつかのパターンがあります。
- 可視性: サブシステムは同じレイヤ内および 1 つ下位のレイヤ内のほかのサブシステムにのみ依存できます。
- 変動性:
- 最上部のレイヤに、ユーザーの要求が変わったときに変化する要素を収めます。
- 最下部のレイヤに、実装プラットフォーム (ハードウェア、言語、オペレーティング システム、データベース、など) が変わったときに変化する要素を収めます。
- 中間層のレイヤに、広範なシステムおよび実装環境に渡って一般的な適用可能な要素を収めます。
- 上記の広範なカテゴリの中で、さらに区分することがモデルの編成に役立つ場合、レイヤを追加します。
- 一般性: 抽象モデル要素はモデルの下位に配置される傾向があります。実装に固有でない要素は、中間のレイヤに引き寄せられる傾向があります。
- レイヤの数: 小規模なシステムの場合、3 つのレイヤがあれば十分です。複雑なシステムの場合では、通常は 5 ~ 7 レイヤで十分です。複雑性の度合いがどの程度であれ、レイヤ数が 10 を超えるシステムについては、その数が多ければ多いほど、疑問を強めて検討すべきです。経験則の一部を下に示します。
クラス数 |
レイヤ数 |
0 - 10 |
レイヤリングは不要 |
10 - 50 |
2 レイヤ |
25 - 150 |
3 レイヤ |
100 - 1000 |
4 レイヤ |
あるレイヤ内のサブシステムおよびパッケージは、同じレイヤ内および 1 つ下位のレイヤ内のほかのサブシステムにのみ依存する必要があります。サブシステム間の依存関係をこのように限定し損なうと、アーキテクチャの品質が低下し、システムがもろく保守しにくくなります。
例外があります。サブシステムが下位のレイヤのサービスに直接アクセスする必要がある場合です。印刷、メッセージ送信など、システム全般にわたる根本的なサービスの処理方法は慎重に決定する必要があります。中間レイヤにコール パススルーを効果的に実装するという方法をとる場合は、下部レイヤへのメッセージを制限する意味はほとんどありません。
システムの最上部において、さらにパーティションを分けることがモデルの編成に役立つことがあります。検討すべき課題別に、パーティショニングに関するガイドラインを以下に示します。
- ユーザーの組織: ビジネス組織内の業務機能構成を反映する線に沿ってサブシステムを編成できます (たとえば、部門別にパーティショニングを行います)。この形のパーティショニングは設計の初期によく発生します。なぜなら、既存のエン タープライズ モデルは組織的に区分された強力な構造をしているからです。この組織パターンは通常はアプリケーションに固有なサービスの最上部の数レイヤだけに影響し、設計が進むにつれて消えていくことがよくあります。
- ユーザー組織の線に沿ったパーティショニングはモデルのよい出発点となり得ます。
- ユーザー組織の構造は長期的には安定していません (ビジネスの再編成があるために)。したがって、それはシステムのパーティショニングの長期的な基盤としては適当ではありません。システムの内部構造は、それがサポートするビジネスの組織から独立して、発展および保守できる必要があります。
- 能力やスキルの領域: モデルの一部に関して、開発組織内の種々のグループ間で責務を区分するように、サブシステムを編成できます。通常、これはシステムの中間部および下部のレイヤで発生し、複雑なインフラストラクチャ技術を開発しサポートする間のスキルを特殊化する必要性を反映します。そのような技術の例として、ネットワークおよび分散の管理、データベース管理、通信管理、プロセス制御などが挙げられます。主要なビジネス機能を理解してサポートするために、問題領域における特殊な能力が必要とされる上部のレイヤにおいても、能力の線に沿ったパーティショニングが発生します。その例として、遠距離通信の呼び出し (コール) 管理、有価証券の取引、保険金の請求処理、航空管制などが挙げられます。
- システムの分散: システムの任意のレイヤ内で、機能の物理的な分散を反映するために、レイヤをさらに「水平的」にパーティショニングできます。
- 分散を反映するためのパーティショニングは、システムが稼働するにつれて発生するネットワーク通信を視角化するのに役立ちます。
- ただし、分散を反映するためにパーティショニングを行うと、配置モデルが大幅に変化したときに、システムを変更しにくくなります。
- 機密領域: アプリケーションの中には、セキュリティ上のアクセス権限の線に沿って、さらにパーティショニングを必要とするものがあります。機密領域へのアクセスを制御するソフトウェアは、適切な許可を得ている要員によって開発および保守されなければなりません。その背景知識に通じた要員の数がプロジェクト内に限られているなら、特別な許可を必要とする機能をサブシステムとしてパーティショニングして、ほかのサブシステムからは独立して開発する必要があります。そのサブシステムへのインターフェイスだけが機密領域の目に見える部分となります。
- オプション領域: オプションであり、そのためにシステムのバリエーションにおいてのみ提供される機能は、システムに必須の機能とは別に開発および提供される独立したサブシステムに編成する必要があります。
|