論理アーキテクチャの設計
📅
UPの成果物の関係例（UP Artifact Relationships） 🔗
UPの成果物は、論理アーキテクチャ（LA）に影響します。
- 主な入力は、補足仕様書に記録されたアーキテクチャ上の設計要因です。
論理アーキテクチャは、ソフトウェアのクラスが定義される
パッケージ
を定めます。UMLパッケージ図（UML Package Diagram） 🔗
設計モデル
の一部としてLAを説明します。
ソフトウェアアーキテクチャ文書
で、1つのビューにまとめられます。論理アーキテクチャとレイヤー（Logical Architecture and Layers） 🔗
論理アーキテクチャ
ソフトウェアのクラスを、パッケージ、サブシステム、レイヤーとして大きく整理することです。
OSのプロセスやネットワーク上の物理コンピューターに、どう配置するかはここでは決めません。
レイヤー
まとまりのある責務を持つクラス、パッケージ、サブシステムの強く結び付いた集合です。
上位
のレイヤーは下位
のサービスを呼び出します。呼び出しの方向は上位から下位です。
オブジェクト指向システムで一般的なのは、ユーザーインターフェース（UI）、アプリケーションロジックとドメインオブジェクト、技術サービスなどのレイヤーです。厳格なレイヤー構造と緩やかなレイヤー構造（Strict vs Relaxed Layered Architecture） 🔗
厳格なレイヤー構造
各レイヤーは、すぐ下にあるレイヤーのサービスだけを呼び出します。
ネットワークプロトコルスタックで一般的です。
緩やかなレイヤー構造
各レイヤーは、複数のレイヤーのサービスを呼び出せます。
例えばUIレイヤーは、すぐ下のアプリケーションロジックレイヤーに加え、ログ記録などの技術サービスレイヤーの要素も呼び出せます。
情報システムで一般的です。
ソフトウェアアーキテクチャとは（What is Software Architecture?） 🔗
ソフトウェアシステムの基本的な構造と仕組みを作る分野です。
各構造には、ソフトウェアの要素、それらの関係、各要素の属性が含まれます。
UMLの適用 - パッケージ図（UML Applied: Package Diagrams） 🔗
UMLパッケージ図
は、論理アーキテクチャの説明によく使われます。- レイヤー、サブシステム、Javaでいうパッケージなどを含みます。
- 例えばUIレイヤーは、UIパッケージとしてモデル化されます。
UMLパッケージ図は、要素を
グループ化
する方法を提供します。- UMLのパッケージには、クラス、ほかのクラス、ユースケースなど、さまざまな要素をまとめられます。
- パッケージを入れ子にすることも一般的です。
パッケージの依存関係（Package Dependencies） 🔗
パッケージ間の依存関係は、パッケージ図に示します。
- 開発者は、システム内の大きな単位同士の結合を把握できます。
- パッケージ間の依存関係は、依存線（dependency line）と呼ぶ破線の矢印で示します。
レイヤーを使った設計（Designing with Layers） 🔗
システムの大きな論理構造を整理します。
- 関心を明確に分離し、関係する責務ごとに独立したレイヤーに分けます。
- 下位のレイヤーは低水準の汎用サービスを提供し、上位のレイヤーはアプリケーションに特化します。
協調や依存の方向は、上位のレイヤーから下位へ向かいます。
下位から上位への結合は避けます。
例（論理アーキテクチャの一般的なレイヤー） 🔗
- UI（ユーザーインターフェース）レイヤー
- アプリケーションロジック（Application Logic）レイヤー
- ドメインオブジェクト（Domain Object）レイヤー
- ビジネス基盤（Business Infrastructure）レイヤー
- 技術サービス（Technical Services）レイヤー
- 基盤（Foundation）レイヤー
レイヤーを使う利点（Benefits of Using Layers） 🔗
関心事、高水準と低水準、アプリケーション固有の機能と汎用サービスを分けられます。
- 結合度と依存関係を減らせます。
- 凝集度を高められます。
- 再利用しやすくなります。
- 構造がわかりやすくなります。
関連する複雑さはカプセル化され、分解できます。
一部のレイヤーは新しい実装に置き換えられます。
- 低水準の技術サービスや基盤レイヤー（java.utilなど）では一般に難しいですが、UI、アプリケーション、ドメインのレイヤーでは可能です。
下位レイヤーには、再利用できる機能を含められます。
主にドメインや技術サービスのレイヤーなど、一部は分散配置できます。
論理的な分割により、チーム単位で開発しやすくなります。
ドメインレイヤーとドメインオブジェクト（Domain Layer and Domain Objects） 🔗
ドメインオブジェクト
- 現実のドメインと似た名前や情報を持つソフトウェアオブジェクトを作り、アプリケーションロジックの責務を割り当てます。
- 問題の対象領域にある何かを表し、関連するアプリケーションロジックやビジネスロジックを持ちます。
ドメインレイヤー
- アプリケーションロジックの処理にドメインオブジェクトを使うレイヤーです。
オブジェクト指向の開発者は、現実のドメインを手がかりにソフトウェアのクラスを作ります。
これにより、関係者のドメインに対する理解と、ソフトウェア内での表現との差が小さくなります。
ティア、レイヤー、パーティション（Tiers, Layers, and Partitions） 🔗
ティア
- 物理的な処理ノード、またはノードのクラスタを指すソフトウェアコンポーネントです。
- クライアントティアがクライアントコンピューターを指すときの用法です。
レイヤー
- システムを縦方向に分けた区画です。
パーティション
- 比較的平坦なサブシステム（レイヤー）を横方向に分けた区画です。 例えば技術サービス（Technical Service）レイヤーは、セキュリティ（Security）やログ記録（Logging）などのパーティションに分けられます。
モデルとビューを分離する原則（Model-View Separation Principle） 🔗
- UI以外のオブジェクトをUIオブジェクトに直接つないだり、結合したりしません。
- アプリケーションロジックをUIオブジェクトのメソッドに入れません。
SSD、システム操作、レイヤー構造の関係（Connection between SSD, System Operations, and Layering） 🔗
適切に設計されたアーキテクチャでは、次のようになります。
- UIレイヤーのオブジェクトは、UIレイヤーで受け取ったシステム操作の要求をドメインレイヤーに転送または委譲します。
- UIレイヤーからドメインレイヤーに送るメッセージは、SSDに記述されるメッセージです。
