SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

IDDD本から理解するドメイン駆動設計

実践DDD本 第14章「アプリケーション」~ドメインモデルを利用するクライアント~

IDDD本から理解するドメイン駆動設計 第14回

  • X ポスト
  • このエントリーをはてなブックマークに追加

複数の境界づけられたコンテキストの統合・合成

 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本では好みや最終目標のトレードオフにて選ぶことを推奨しています。

次のページ
アプリケーション層における実装

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
IDDD本から理解するドメイン駆動設計連載記事一覧

もっと読む

この記事の著者

WINGSプロジェクト 青木 淳夫(アオキ アツオ)

WINGSプロジェクトについて>有限会社 WINGSプロジェクトが運営する、テクニカル執筆コミュニティ(代表 山田祥寛)。主にWeb開発分野の書籍/記事執筆、翻訳、講演等を幅広く手がける。2018年11月時点での登録メンバは55名で、現在も執筆メンバを募集中。興味のある方は、どしどし応募頂きたい。著書記事多数。 RSS X: @WingsPro_info(公式)、@WingsPro_info/wings(メンバーリスト) Facebook

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

山田 祥寛(ヤマダ ヨシヒロ)

静岡県榛原町生まれ。一橋大学経済学部卒業後、NECにてシステム企画業務に携わるが、2003年4月に念願かなってフリーライターに転身。Microsoft MVP for Visual Studio and Development Technologies。執筆コミュニティ「WINGSプロジェクト」代表。主な著書に「独習シリーズ(Java・C#・Python・PHP・Ruby・JSP&サーブレットなど)」「速習シリーズ(ASP.NET Core・Vue.js・React・TypeScript・ECMAScript、Laravelなど)」「改訂3版JavaScript本格入門」「これからはじめるReact実践入門」「はじめてのAndroidアプリ開発 Kotlin編 」他、著書多数

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/11221 2018/11/21 14:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング