SHOEISHA iD

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

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

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

実践DDD本 第9章「モジュール」~高凝集で疎結合にまとめる~

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

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

 ドメイン駆動設計(DDD)は、顧客と開発者が業務を戦略的に理解し、共通の言葉を用いてシステムを発展させていく設計手法です。前回は「ドメインイベント」について紹介しました。9回目となる今回は「モジュール」について紹介します。

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

モジュールとは

 「モジュール」とは、オブジェクトをまとめて管理する仕組みのことを表します。プログラミング言語の機能としては、Javaではパッケージ、C#では名前空間と呼ばれています。本稿では、このモジュールをDDDでどのように設計していくかについて紹介していきます。

DDDでのモジュールとは

 「モジュール」はプログラム言語における「パッケージ」や「名前空間」にあたり、クラス群をまとめて管理する入れ物となります。この機能により、クラス群の責任と役割を明確にして、保守性や可読性を上げることができます。DDD本でEvans氏は

 モジュールを選択する際には、システムに関する物語を伝え、概念の凝集した集合を含んでいるものを選ぶこと。こうすることで、モジュール間は低結合になることが多い。(略)モジュールとその名前はドメインに対する洞察を反映していなければならない。

と、モジュールについて述べています。この説明からわかるように、DDDではソースファイルを物理的に分けるだけではなく、高凝縮で低結合なモジュール化されたモデルを、ユビキタス言語に従って構築することを推奨しています。

DDDの「モジュール」とは
DDDの「モジュール」とは

 簡単な例を見てみましょう。上図では「道具」という1つのモジュールを、「キッチン引き出し」と「ガレージ工具箱」の2つのモジュールに分割しています。ナイフ、フォーク、お皿はキッチンで一緒に使う(依存関係があり凝集性が高い)ため同じモジュールにしています。そして、一緒に使わない(結合度が低い)ガレージ工具類を別のモジュールとして設計しています。

 このように、モジュール設計では凝集度と結合度の両方を意識します。

高いほど好ましい「凝集度(ぎょうしゅうど)」

 凝集度(cohesion)とは、モジュールのまとまり具合に関する指標です。特定の機能に対する責任を持って、正しくまとまって協調しているかを示す指標で、高いほうが良いとされます。文脈的に強度(strength)と呼ばれることもあり、この場合は強いほうが良いとされます。

低いほど好ましい「結合度」

 結合度(coupling)とは、モジュールを変更しやすいように適切に分割できているかどうかを示す指標です。密結合(結合度が高)なシステムでは修正が困難になるため、疎結合(結合度が低)なシステムが良いとされます。

 必要な機能がまとまっていれば、外部のモジュールと連携する必要がないため、凝集度が高くなれば、結合度は低くなります。逆に、凝集度が低くなれば結合度が高くなる傾向があります。言うまでもなく、特定モジュール内の変更が別のモジュールに影響を与えてしまうような、低凝集かつ高結合のシステムは好ましくありません。

モジュールの設計方法

 モジュール設計における重要なポイントとして、まず「モジュールの存在を軽視しない」ことを挙げています。エンティティ/値オブジェクト/サービス/イベントと同じ扱いで、モジュールについても十分に議論するようにします。

 モデリングする際には、正確な意図が伝わるようにモジュール名を検討します。必要があれば恐れずにモジュール名の変更を行います。ドメインエキスパートとディスカッションしている最新情報がモジュールに反映されるように努めます。

IDDDにおけるモジュールの設計ルール

 IDDDではモジュールを設計する指針として、以下を整理しています。

IDDDにおけるモジュールの設計ルール
番号 モジュールの設計指針
1 モジュールをDDDにおいて非常に重要な概念と認識し、モデリングの概念にフィットさせ設計する。例えば、集約に対して1つのモジュールを用意する。
2 モデリングの概念に従い、モジュール名をユビキタス言語に従う。
3 モジュール名を機械的に決めない。例えば、クラスの型や役割だけでまとめるようなモジュールを作らない。
4 疎結合に設計する。極力、他のモジュールに依存しないようにする。
5 モジュール同士の結合が必要な場合に、循環依存が起きないようにする。意味的に双方向な依存関係があっても実装上は単一方向の依存関係が望ましい。
6 モジュール間の循環依存は避けるべきだが、親子関係(上位と下位関係)のモジュールに限り、やむをえない場合がある。
7 取りまとめているオブジェクト群に合わせた名前をつけ、そぐわない場合はリファクタリングする。

 これらの指針では、ユビキタス言語や凝集度、結合度、依存関係(循環参照)といった観点を意識していることがわかります。

会員登録無料すると、続きをお読みいただけます

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

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

メールバックナンバー

次のページ
モジュールの命名規約

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

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

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

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

おすすめ

アクセスランキング

アクセスランキング

イベント

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

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

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

メールバックナンバー

アクセスランキング

アクセスランキング