【.NETのエンタープライズアプリケーションアーキテクチャ】の第二部 アーキテクチャの考案 まとめ
概要
- プレゼンテーション層とビジネス層に着目。
- UXファーストと呼ばれるタスクベースの手法の説明。
- ドメインを深く理解することだけが適切なアーキテクチャの発見につながり、結果として得られたアーキテクチャがアプリケーション全体をカバーする単一のトップレベルアーキテクチャとは限らず、サブドメインに気づいた場合はサブアプリケーションをモデリングし、最適なアーキテクチャをそれぞれに定義する。
第5章 ドメインアーキテクチャの発見
- ソフトウェアには、現実の世界を正確に映し出すことが期待される。
- ソフトウェアアーキテクトは、ソフトウェアが現実の世界のどの部分をモデリングしているかを理解する必要がある。
- その部分はビジネスドメインであり、それぞれに理想的なアーキテクチャ（階層化アーキテクチャやヘキサゴナルアーキテクチャなど）を必要とする複数のビジネスコンテキストを含んでいるかもしれない。
5.1 ドメイン駆動設計（DDD）の本当の付加価値
- DDDは、特定のビジネスドメインに関する知識を噛み砕き、それを忠実に反映したソフトウェアを作成するためのもの。
- ビジネスドメインは、企業が業務を行う方法であり、組織、プロセス、実務、人々、言語に関連している。
- ビジネスドメインが存在するのは、コンテキストの中であり、非常に似ているビジネスであっても、コンテキストが異なる可能性がある。
DDDの利点
- DDDを使用する上で肝心なのは、その本当の価値がどこにあるかを理解し、それを利用する方法を学ぶこと。
- DDDの分析部分は、ビジネスドメインのトップレベルアーキテクチャを境界付けられたコンテキストで表現する方法を定義。
- DDDの戦略部分は、特定された境界付けられたコンテキストをサポートするたのアーキテクチャの定義に関連。
- DDDの本当の付加価値は、ビジネスコンテキストの境界を定義するために分析部分を使用することにあり、その後、境界付けられたコンテキストのいずれかを実装するために戦略部分が利用される。
DDDを使った分析
- DDDの分析部分は、ユビキタス言語と境界付けられたコンテキストという2つの関連する要素で構成。
- ユビキタス言語は、プロジェクトの関係者全員が使用する言語。ユビキタス言語は、最終的にクラス名やメソッド名で使われる。
- 境界付けられたコンテキストは、ドメインの様々な領域のうち、独自のユビキタス言語を持つために別個に扱ったほうが効果的な領域を表すDDDの用語。ビジネスドメインはどれも複数のコンテキストで構成され、コンテキストにはそれぞれ論理的な輪郭がある。
- DDDの分析部分を表すためによくコンテキストマッピングという表現が用いられる。ソフトウェアアーキテクトの視点からドメインを俯瞰的に定義し、サブドメインとそれらの関係を明らかにし、戦略的な決断を下すのに役立つ。
戦略的なモデル設計
- さまざなな境界付けられたコンテキストを定義したら、それぞれに最適なサポートアーキテクチャを決定する必要がある。
- 最適なサポートアーキテクチャを選択する基準は、今のところソフトウェアの寿命がどれくらいかに基づく。寿命が長ければ、ドメインモデルのパターンを採用する価値がある。現時点のドメインモデルパターンだと、ドメインのモデルを中心に設計された階層化アーキテクチャをDDDが提案している。
5.2 ユビキタス言語
ユビキタス言語の目的
- ビジネスの言語から開発の言語への翻訳を手配し、専門用語をビジネスor開発のコンテキストに合わせて調整していると、時間がかかり、途中で抜け落ちてしまう可能性がある。
- ユビキタス言語の目的は、すべての関係者がすべてのレベルで使用する共通用語を定義すること。
- 共通用語があれば、ビジネスのコンテキストから開発のコンテキストへ概念の翻訳する必要がなくなり、明確さが促進され、仮定しなければならないことが最小限に抑えられる。
ユビキタス言語の構造
ユビキタス言語を定義する方法
- ユビキタス言語は、聞き取り調査や話し合いの中から現れ、徐々に最終的なカタチをなしていく。
- 言葉が期待どおりに伝わり、構築中のシステムの現実を忠実に表すようになるまでに、改良や調整が何度も必要になるかもしれない。
言語とモデルの同期
- ドメインモデルで使用される言葉とユビキタス言語の言葉を常に反映させるべき。
- ビジネスコンテキストに属さない技術的な詳細（オブジェクトインスタンスとか、テーブルからデータを取得するとか）は、実装の内側に埋め込み、開発者どうしの技術ミーティングでのみ取り上げ、ビジネス側の人々との正式なコミュニケーションに含まれないようにすべき。これがユビキタス言語の本質。
5.3 境界付けられたコンテキスト
- 境界付けられたコンテキストとは、独自のユビキタス言語とアーキテクチャを必要とするアプリケーションの領域のこと。
- 別の言い方をすれば、境界付けられたコンテキストの境界内では、ユビキタス言語は1つであり、境界付けられたコンテキストは他の境界付けられたコンテキストとの間に関係を持つことができる。
コンテキストの発見
- 新しいサブドメインを発見するための最初の手がかりは、既知の概念を表現するために新しい用語が使用されていることや、同じ用語に2つ目の意味があるこを発見したとき。これはサブドメインの重複を示唆。最初の決断は、それらのサブドメインを別々に扱う必要があるかどうか。
- 組織の構造を反映したコンテキストが作成される場合が特に効果的。
- 概念の重複が検出されたときに解決しなければならないのは、以下の選択肢のうちどれがより適切であるか。である。
- すべてのエンティティを含んでいる単一の境界付けられたコンテキスト。（コンテキストは1つ）
- 共通のエンティティを共有カーネルとして定義する別個の境界付けられたコンテキスト。（コンテキストは3つ）
- 共通のエンティティの異なる定義を持つ別個の境界付けられたコンテキスト。（コンテキストは2つ）
コンテキストマッピング
- 多くの場合、境界付けられたコンテキストの間には関連性があり、DDDのコンテキストマップは、設計中のシステムの全体図となる。つまり、各要素が境界付けられたコンテキストであり、それらの関連性を表現する。
コンテキストごとにアーキテクチャを定義する
| 名前 | 説明 |
|---|---|
| 階層化アーキテクチャ | プレゼンテーション層、ビジネス層、データ層に基づく標準的な切り分け。 |
| ドメインモデル | プレゼンテーション層、アプリケーション層、ドメイン層、インフラストラクチャ層の4のレイヤーに基づき、DDDスタイルで設計された階層化アーキテクチャ。とりわけ、ドメインモデルが特殊なオブジェクトモデルと位置づけ。 |
| コマンド/クエリ責務分離（CQRS） | コマンド部分とクエリ部分を処理するための並列セクションを持つ2重の階層化アーキテクチャ。これらのセクションは別々に設計することが可能で、異なるサポートアーキテクチャを使用することが可能。 |
| イベントソーシング | CQRSにヒントを得て、単純なデータではなく、イベントのロジックに焦点を合わせた階層化アーキテクチャ。 |
5.4 階層化アーキテクチャ
プレゼンテーション層
- プレゼンテーション層では、タスクを実行するためのユーザーインターフェースを提供する必要がある。
- プレゼンテーション層に表示されるデータをビューモデルと呼ぶ。画面から送信されてバックエンドのアクションを開始するデータを入力モデルと呼ぶ。
アプリケーション層
- アプリケーション層は、プレゼンテーション層の指示に従ってビジネスアクションを手配するレイヤー。
- アプリケーション層は、ユースケースの実装を取りまとめる場所。
- アプリケーション層は、ドメイン層およびインフラストラクチャ層への参照を保持し、ビジネスルールをいっさい認識せず、ビジネス関連の状態情報を保持しない。
ドメイン層
- ドメイン層は、1つまたは複数のユースケースに限定されないビジネスロジック全体をホストするレイヤー。
- つまり、アプリケーション層を組み立てた後に残ったビジネスロジックを全て含む。
- ドメインモデルの最終目標は、ユビキタス言語を実装し、ビジネスプロセスが要求するアクションを表現すること。これらの点に関しては、何らかのデータを保持することよりも、何らかの振る舞いを提供することのほうに分がある。
インフラストラクチャ層
- インフラストラクチャ層は、具体的なテクノロジに関するあらゆるもので構成される。
- EntityFramuworkといったO/RMフレームワークによるデータの永続化や、ログ、IoCコンテナなど様々。
- ただ、一番代表するコンポーネントは永続化のレイヤーである。
第6章 プレゼンテーション層
6.1 ユーザエクスペリエンスファースト
- ユーザエクスペリエンスファーストは、ユーザ/システム間のやり取りとプレゼンテーションを中心に据えたソフトウェア設計アプローチである。
やり取りに着目する
- ユースケース図を作成するところから始める。各ユースケースに必要な入力、各ユースケースが生成する出力に焦点を合わせるアプローチ。
- データではなく、やり取りに焦点を合わせてスケッチを手直ししていくのが進むべき道。
第7章 伝説のビジネス層
- 従来のデータ中心の3層構造の世界から、モデル中心の階層化された世界えの転換の正当性を示すとともに、実際に展開を図る内容となっている。
7.1 ビジネスロジックを構造化するためのパターン
Transaction Scriptパターン
- Transaction Scriptは、ユースケースと一対一でクラス設計していくパターン。
- Transaction Scriptパターンが適しているケース。
