複数の境界づけられたコンテキストの統合・合成
1つのUI画面にて、複数の境界づけられたコンテキストの情報が必要になる場合があります。例えば、3つのコンテキストをアプリケーションサービスでまとめる必要がある場合をみてみましょう。大きく次の2つの方法があります。
最初の方法として、複数の境界づけられたコンテキストに対して、アプリケーション層からアクセスして合成する方法があります(上図左)。
次に、境界づけられたコンテキストを新しく作る方法があります(上図右)。このコアドメインは、新しいモデルと腐敗防止層から構成される軽量な役割となります。トランザクションスクリプトでもあり、ドメインモデル貧血症となりますが、そのようなコンテキストとして割り切ります。
どちらの方法を選ぶかという基準は、ビジネス上のメリットが大きいほうを選びます。以上、UI層からのリクエストに応じて、集約の情報を提供する方法を紹介してきました。
UI層での描画に関わるモデル
ここまで、ドメイン層の情報をクライアント側に公開する仕組みについて見てきました。続けて、UI側での描画について見ていきましょう。
「ビュー」と「プレゼンテーションモデル」
UIを描画するフレームワークはさまざまですが、
- UIの表示(描画)を行う「ビュー」
- UIの状態とUI固有ロジックを持つ「プレゼンテーションモデル」
の2つから構成されることがよくあります。この場合、プレゼンテーションモデルの状態に基づいてビューが画面のレンダリングを行います。
さまざまなモデルの役割
これまで紹介してきたように、システム全体を通して、さまざまな種類のモデルが存在しています。
まず、ドメインモデルはユビキタス言語を用いて、ビジネスや業務そのものを表現します。次にDTO/DPOはクライアントに対して、ユースケースに応じたデータ構造の公開と受け渡しを担当します。
プレゼンテーションモデルは画面の内容を抽象化し、UI固有の振る舞いを担当するモデルとなります。そのため、画面に必要な機能をドメインモデルに実装するのではなく、プレゼンテーションモデルに用意するようにします。プレゼンテーションモデルはUIのニーズに合わせたプロパティや振る舞いを持ち、必要な情報をドメインモデルから取得します。
また、RESTfulで提供するリソースも1つのプレゼンテーションモデルであるとヴァーノン氏は伝えています。
[コラム]UI層にドメインモデルを公開するかの判断
DPOを利用する場合、UI層からドメインモデルを見ることができます。逆にDTOを利用する場合、UI層に対してドメインモデルを隠すことができます。この両者の設計指針としては次のものがあります。
項目 | ドメインモデル公開時 | ドメインモデル非公開時 |
---|---|---|
性能 | ○(変わらない) | △(DTO詰め替えによるメモリ使用とガベージコレクションコストが発生) |
依存関係 | △(ドメインモデルへの依存性が高く結合度が高い) | ○(ドメインモデルへの依存がなく結合度が低い) |
型による妥当性チェック | ○(使える) | △(使えない) |
コード量 | ○(増えない) | △(DTO部分や詰め替え部分が増える) |
複数クライアント時の対応 | △(ドメインモデルにおいて影響がないように複数クライアントを考慮する) | ○(複数クライアント別にDTOを用意するためドメインモデルに影響がない) |
ドメインモデルを公開すればユビキタス言語で使いやすく、バリデーションチェックが有効なモデルを利用できるといったメリットがあります。しかし、UIとドメインモデルが密結合となるため相互に変更の影響を受けやすくなります。
逆に、ドメインモデルを非公開にすれば、UI層は、DTOとプリミティブ型(Int,String等)のみを参照することになります。これによりUIとドメインモデル間を疎結合にできますが、中間的なメッセージモデルへの詰め替えコードが冗長になってしまいます。
IDDD本では好みや最終目標のトレードオフにて選ぶことを推奨しています。