ドメイン駆動設計 ドメインモデルの役割

ドメイン駆動設計の必要性

アプリケーション開発において、ドメイン駆動設計を使えば必ず成功し、使わなければ失敗するということではありません。

ただ、失敗とまではいかなくても、80点のシステムもあれば、40点のシステムも存在します。

点数の物差しは様々ありますが、より優れたシステムを作るためには、自分流や社内流だけではなく、他の手法を学ぶことも大切です。

ドメイン駆動設計のように広く評価されている手法であれば、なおさらです。

そのすべてが役立つこともあれば、小さな気づきになることもあるでしょう。

ドメイン駆動設計は、オブジェクト指向やモデル駆動の経験者には、次に進むべき方向を示した、心強いガイドです。

むしろ、DDD本に書かれていることの多くは、すでに実践中かもしれません。

他方で、ドメイン駆動設計の主張や必要性が分かり難いと感じる方もおられるでしょう。

ドメイン駆動設計を分かり難くする要因のひとつに、次に述べるようなアンチパターンの存在があると思います。

そこで、まず、アンチパターンについて知っておくと、理解しやすいかもしれません。

利口なUIを卒業

「利口なUI」や「トランザクションスクリプト」と呼ばれるパターンがあります。

これらは、ドメイン駆動設計やオブジェクト指向では、アンチパターンの１つです。

しかし、実際には (特に業務系のシステムでは)、このパターンで作られたシステムは、たくさん存在しています。

そのため、それらがアンチパターンであるという指摘は受け入れ難いようです。

※トランザクションスクリプトは、マーチン・ファウラー氏の著書「エンタープライズアプリケーションアーキテクチャパターン」に示されています。

例として、Struts系のフレームワークを使ったWebアプリケーションを考えてみます。

もし、Webアプリケーションが下図のような構造になっていれば、それは「利口なUI」パターンです。

下図は、「利口なUI」や「トランザクションスクリプト」で作られたアプリケーション構造の例です。

上図の (A) や (B) では、JSPやアクションの中にSQL文が組込まれていて、そのSQL文で多くの業務ロジックを実現します。

そして、同じような、あるいは全く同じSQL文が、JSPやアクションの中に散在しています。

(C) では、Modelと称するクラスがありますが、実態は、DAOやDTOと呼ばれるような実装上の役割 (バケツリレーのバケツ) しか持っていません。

(A) (B) と同様にSQL文が重複したり散在します。

そして、ドメインの本質的な振る舞い (ビジネスロジック) は、ほぼ各画面の都合に合わせたSQL文で実現されているでしょう。

なお、一部のORMフレームワークなどを使って、SQL文を隠ぺいしているだけであれば、問題は同じです。

オブジェクト指向の場合は、オブジェクトはそれにふさわしい名前と責務を持ちます。

そして、それらが協調することでビジネスロジックを実現します。

ふさわしい名前と適切に割り当てられた責務は、そのオブジェクトの役割を見通しやすくし、再利用と変更を容易にします。

しかし、SQLで実現されたロジックの多くには、オブジェクトの存在や役割に相当する概念は無く、いくつかのデータエンティティに跨った、画面都合の処理になっています。

そのため、コードの目的が分かり難く、再利用も変更も難しい場合が多いです。

最初は大きな問題ではなかったとしても、すぐにソフトウェア・エントロピー (複雑度) が増大し、手に負えなくなるでしょう。

ドメイン駆動設計を始めるためには、ドメイン駆動設計的にもオブジェクト指向的にも、これらがアンチパターンであるという認識が必要です。

しかし、「利口なUI」には悩ましい利点もあります。

利口なUI の利点

DDD本には次のように書かれています。

※引用：ここから (DDD本の第4章 p.75)

  ● 単純なアプリケーションの場合、生産性が高く、すぐに作れる。

  ● それほど有能でない開発者でも、この方法ならほとんど訓練しないで仕事ができる。

※引用：ここまで (引用元には箇条書きで他に5点示されています)

なぜ悩ましいかというと、この点について疑問に思わない管理者や開発者も多いからです。

多数の開発者を一時的に集めて作業をするようなプロジェクトにおいては、都合の良い面もあるかもしれません。

しかし、プロジェクトの後半や仕様変更の時、あるいは保守・改修といった局面においては、これらが利点となっているケースは皆無に近いのではないでしょうか。

分析・設計やアーキテクチャのリファクタリング (洗練) 不足が表面化するのは、開発の初期局面ではなく後半です。

経験上、「生産性が高く、すぐに作れる」という現象は、開発の極めて初期の段階に限られます。

一般に、開発の後半で問題が生じてきても、開発者の人数不足などが原因とされることがほとんどです。

そして、いつもの問題として、許容されているかのようです。

実はその原因が、手法やアーキテクチャの問題とされることは少ないように思われます。

ドメイン駆動設計を習得し実践していくためには、「利口なUI」の問題点を理解しておくことが必要かと思います。

DDD本には「利口なUI」の欠点についても次のように書かれています。

利口なUI の欠点

※引用：ここから (DDD本の第4章 p.75)

  ● アプリケーションの統合は困難で、データベースを経由させるしかない。

  ● ふるまいが再利用されことも、ビジネスの問題が抽象化されることもない。ビジネスルールは、適用先の操作それぞれで複製されることになる。

※引用：ここまで (引用元には箇条書きで他に2点示されています)

「利口なUI」に起因する問題点については、実際に経験されている方は多いのではないでしょうか。

特に開発工程の後半や、保守や改修作業において、エントロピーの増大に悩まされた方は少なくないでしょう。

ドメイン駆動設計は、これらの問題を引き起こさないため提案です。

基本の捉え方

では、ドメイン駆動設計の基本について考えたいと思います。

ドメイン駆動設計を解説した情報は、書籍やネット等でたくさん見つかります。

どれも同じことを言っているようですが、少しずつ違うように感じることも少なくありません。

DDD本自体も500ページ超のぶ厚い本です。

読者の技術経験や関心事などによっても、受け入れやすいポイントもあれば、理解できない内容もあるはずです。

やはり、ドメイン駆動設計を実践していく中で、自分なりの捉え方を作り上げていくものだと思います。

本記事においては、次のように考えています。

ドメイン駆動設計の要点は、

  ● アプリケーションの本質はドメインである。（実装のためのフレームワークやアーキテクチャは本質ではありません）

  ● ドメインを抽象化したドメインモデルをアプリケーションの土台にする。

  ● ドメイン知識からユビキタス言語を導き出し、チーム内のコミュニケーションに使用する。

  ● ユビキタス言語の語彙は、ドメインモデルのクラス名やメソッド名、サービス名などと常に整合させる。

  ● ドメインモデル、実装コード、ユビキタス言語 の３つを常に一致させて、アプリケーションをイテレーティブに構築する。

  ● DDD本に示されたモデリングパターンやガイドラインの中から、自分に適したものを見つけて、アプリケーションの設計・構築に活用する。

いきなり、DDD固有のキーワードを使いましたが、後で説明します。

手法的には、すでに実績のある３つの手法と、そこで培われたノウハウを活用します。

  ● モデル駆動開発

  ● オブジェクト指向技術

  ● アジャイル開発

そして、いくつかの指針を追加します。

  ● 「ドメインモデル貧血症」と言われるような、責務が欠落したクラスは作らない。（貧血症のクラス群をドメイン層とは呼びません）

  ● 「分析モデル」や「設計モデル」のように、工程や担当によってモデルを分離しない。

  ● 1つのモデルを作成し、それを継続的に洗練し、使い続ける。即ち、全工程を通して各オブジェクトは追跡可能にする。

  ● コミュニケーションやドキュメントの記述には、ユビキタス言語の使用を徹底する。

  ● ユビキタス言語、モデル、実装の間に整合性を保ち、相互に追跡可能にする。

ドメイン駆動設計の始め方

ドメイン駆動設計を始める時の基本方針として、次のことを推奨します。

・ドメイン駆動設計を必要以上に難解に解釈しようとしない。

・最初から多くのことを実践しようとしない。

・チーム内で (後述の)「最初の壁」を共通認識する。

・ドメインモデルは反復型で開発する。

・スキルアップも反復的に行う。

まず最初は、ドメイン内の幾つかのコアモデルから始めることを推奨します。

コアモデルとは、例えば、対象ドメインが病院業務であれば、「医師」や「病室」などです。

できれば、主要なオブジェクトで、かつ、オブジェクト記述を書きやすいオブジェクトが良いと思います。

オブジェクト記述とは、そのオブジェクトが何ものかを定義した短い文章です。

オブジェクト名やオブジェクト記述に含まれる単語は、「ユビキタス言語」の語彙です。

オブジェクト記述は、設計開発が進捗するにつれて、より専門的で深くなっていくでしょう。

開発が進むと、他のオブジェクトも次第に出現してきます。

[例] オブジェクト名：医師

オブジェクト記述：医師免許を有し、医療および保健指導を行う役割。

そして、ドメインモデルのリファクタリングを繰り返しながら、設計スキルとドメインモデルの両方を、段階的に洗練していきます。

いろいろなモデリングパターンやプラクティスを、一気に取り入れて使いこなすのは難しいことです。

それらは、段階的に取り入れ、体得し、ドメインモデルとともに深めていくことが重要です。

一方で、開発が進むにつれて、1回の繰り返し (イテレーション) が重くなっていく傾向があります。

ドメインモデルを変更 (リファクタリング) すると、ビュー層や永続化層の実装コードにも影響が及ぶからです。

ドメインモデル以外のビュー層や永続化層の変更は機械的なものが大半で、開発者の集中力は低下します。

現実的な工数や期間では、イテレーションを繰り返せなくなってしまうこともあります。

ドメイン駆動設計に限った話ではありませんが、対策が必要です。

これについては、後述の「反復型開発」で述べます。

最初の壁を見越す

ドメイン駆動設計を始めるときに遭遇しやすい、最初の壁について紹介します。

折角、ドメイン駆動設計やオブジェクト指向に取り組んだけれど、結局、何も変えられないということがあります。

原因の１つは、下図に示すような「立ち上がり期」の停滞感です。

ここでの停滞とは、チームが空回り気味で、具体的な成果物 (例えば、動作するコードなど) が出てこないような状態です。

結局、打開策が見つからずに、利口なUIのようなアンチパターンに後戻りするチームもあります。

つまり、この「立ち上がり期」を通過すれば、ドメインモデルベースの方が良い結果につながるという成功経験や確信が無い場合、ここで挫折してしまうことになります。

過剰な議論なのか、時間だけの問題なのかなど、停滞の状況を冷静に見極める必要があります。

やみくもにDDD本のプラクティスを強行するだけではうまくいかないでしょう。

例えば、実践するプラクティスを1つだけにするとか、経験者やメンターを探す等の対策が必要です。

この立ち上がり期の停滞感を乗り越えなければ、オブジェクト指向やドメイン駆動設計の効果を得られる前に、従来型に戻ってしまうことになります。

求められる知識

ドメイン駆動設計で優れたモデリングを行うには、他の手法やパターンなども参考になります。

• オブジェクト指向モデリング技術 (考え方)
• イテレーティブ開発、インクリメンタル開発、アジャイル開発 (考え方)
• モデル駆動設計 (考え方)
• オブジェクト指向プログラミング
• アナリシスパターンは、ドメインモデルの具体例、パターンです。他のドメインでも参考になるようなドメインモデルの構造、パターンを示します。
• デザインパターンは、オブジェクト指向設計パターン、実装パターンです。

ソフトウェア

一般にソフトウェアとは、コードだけではなく、設計書などのドキュメントを含めたものを指します。

本記事では、下図に示した成果物をソフトウェアまたはアプリケーションと呼びます。

図中の「ユビキタス言語」「ドメインモデル」「ドメインモデルの実装 (ソフトウェアで表現されたモデル)」はドメイン駆動設計のキーワードです。

開発チームと実践的モデラ

ドメイン駆動設計には、開発チームに関して、実践的モデラ・パターンと呼ばれるものがあります。

開発チームは、ユーザ、ドメインエキスパート (業務の専門知識をもつ人) 、ソフトウェア技術者で構成されます。

チーム内では、ユビキタス言語 (後述) を使ってコミュニケーションを行います。

実践的モデラ・パターンでは、分析、モデリング、設計、プログラミングというように、過度に役割を分離しません。

チームメンバー全員が、モデラであり、プログラマであるべき、という考え方です。

しかし、現実問題として、実践的モデラが実現困難な場合もあるでしょう。

そのような場合でも、全員がモデルと実装コードを理解し、関心と責任を持つことが求められます。

ユビキタス言語

ドメイン駆動設計には、ユビキタス言語という概念があります。

どんなチームでもコミュニケーションは重要ですが、どうしても、人や役割によって使用する名詞や動詞の意味が、微妙に違っていることがあります。

ユビキタス言語とは、ドメインエキスパートの知識やドメインモデルをもとに、単語の微妙な違いを排除し、より正確なコミュニケーションを行うためのものです。

ドメインモデルや実装モデルの要素と正確に対応付けができることがポイントです。

ユビキタス言語の語彙は、モデルや実装コードのクラス名、メソッド名などと双方向に追跡可能 (紐付けられる) にします。

※DDD本 p.26 から引用：ここから

「モデルを言語の骨格として使用すること。 チーム内のすべてのコミュニケーションとコードにおいて、その言語を厳格に用いることを、チームに約束させること。 図やドキュメント、そして何より会話の中では同一の言語を使用すること。 言語を使う上で問題があれば、代わりの表現を用いて実験することで、問題を取り除くこと。 そうした表現は代りとなるモデルを反映している。 そこで、新しいモデルに合わせてコードをリファクタリングし、クラス、メソッド、モジュールの名前を変更すること。 会話の中で用語が混同されていたら、普通の単語の意味について認識を合わせるのと同じやり方で解決すること。 ユビキタス言語における変更は、モデルに対する変更であると認識すること。」

※DDD本から引用：ここまで

ドメインモデル

ドメイン駆動設計では、アプリケーションの本質は、システム化対象領域である「ドメイン」です。

ドメインモデルとは、あるドメインに存在する概念を抽象化したものです。

Web アプリケーションでよく使われているレイヤ化アーキテクチャ (後述) のドメイン層に位置するオブジェクト群です。

ドメインモデルは、ユビキタス言語や、UMLなどのモデリング言語、プログラミング言語で定義されます。

ドメインモデルを構成するオブジェクトには、エンティティ、値オブジェクト、サービスがあります。

[例] ドメイン:書店在庫管理, エンティティ:本, 値オブジェクト:ISBN, サービス:在庫移動処理

以下に示します。

エンティティ

ドメイン駆動設計におけるエンティティとは、ドメインモデルを構成するオブジェクトの類型の1つです。

他に、後述する値オブジェクトやサービスオブジェクトがあります。

エンティティは、連続性と識別性 (同一性と同値は区別される) を持ち、システムのライフサイクルを通して一意に識別されます。

ドメイン駆動設計では、多くの場合、オブジェクト指向モデリングを使ってドメインモデルを作成します。

ただ、オブジェクト指向モデリングに慣れていないと、なかなか結果が出せない場合もあります。

もちろん、一気にドメインモデルを作ることは無理ですし、そのために、ドメイン駆動設計では反復型の開発プロセスを採用するわけです。

そこで、オブジェクトを見つけるときのヒントとして、少々古典ですが、「オブジェクト指向システム分析」シュレイアー、メラー著を紹介します。

そこには、オブジェクトの候補として以下が挙げられています。

• 有形物
  • 人、商品、伝票。
• 役割
  • 人や構成により演じられる役割。医師、患者、顧客、従業員。医師は患者にもなる。
• 出来事
  • 飛行、事故、故障、サービス要求。
• 相互作用
  • 買い入れ、結婚。
• 仕様
  • 製品などの仕様。

DOA (データ中心アプローチ) でも、上に挙げたような概念やモノは、テーブルの候補となるでしょう。

そして、それらの概念やモノは、ドメイン駆動設計のエンティティの有力な候補です。

各エンティティの責務や協調者についても、分析、設計、実装を行うことで、ドメイン駆動設計のドメインモデルとなっていきます。

少し乱暴ですが、各論理テーブルは、(かなりの確率で) 妥当なエンティティと言えます。

テーブル名や列名は、そのクラス名や属性名となります。

ただし、テーブルにはありませんが、エンティティは「メソッド」を持ちます。

主にメソッドによって、ドメインにおける責務を実現します。

これは、重要な違いです。

値オブジェクト

ドメイン駆動設計の値オブジェクトとは、ドメインモデルを構成するオブジェクトの類型の1つです。

エンティティとは異なって、識別性を持たない、変更不可の不変 (immutable) オブジェクトで、その属性だけに関心があるようなオブジェクトです。

多くの場合、エンティティオブジェクトの状態を記述する属性として振る舞います。

例として、図形処理アプリケーションの座標点クラス (Point) があります。

多くの場合、エンティティの属性の状態を現すクラスは値オブジェクトとなります。

値オブジェクトには一意性は必要なく、同値性が重要です。

エンティティの属性の状態を示すためには、使用するプログラミング言語のプリミティブ型で十分なケースも多くあります。

例えば、Pointクラスではなくても、実数値を２つ持った２次元配列で十分と思われるケースもあります。

しかし、Pointクラスのような値オブジェクトをドメインモデルに追加することで、ドメインモデルをより洗練できることもあります。

ただし、過度に追加するとクラスの爆発と言われるような状況に陥ることもあります。

エンティティと値オブジェクトの例

このサンプルは、正確な医療情報や知識に基づくものではありませんので注意してください。

患者オブジェクトは、血糖値とヘモグロビンA1cの値から、血糖コントロールの状況を判定して、その結果をメッセージ形式で応答します。

血糖値は、空腹時血糖値、食後血糖値など1日の中でも変動する検査値です。

ヘモグロビンA1c (HbA1c) は、おおよそ2カ月間の平均血糖値を推定できる検査値です。

血糖コントロールとは、運動や食事、薬などで、血糖値を適正範囲に保つことです。

患者オブジェクトが「血糖コントロール状況を応答する」という責務を持たないモデルもあるでしょう。

例えば、次図のように診療記録オブジェクトが「血糖コントロール状況を応答する」責務をもつモデルも考えられます。

また、医師オブジェクトや診断サービスなどを追加すべきかもしれません。

サービス

ドメインには、エンティティや値オブジェクトとして考えると、不自然なものが存在します。

それらは、サービスとしてユビキタス言語とドメインモデルに組み込みます。

サービスは基本的に状態を持ちません。

エンティティや値オブジェクトではなく、アクションや操作といった概念として存在します。

[参考] SPパターンの純粋人工物 (Pure Fabrication)

例えば、在庫管理業務の中に、「倉庫間移動」という業務処理があります。

倉庫間移動とは、「ある倉庫の在庫商品を別の倉庫に移動する」ことです。

ここで、この倉庫間移動は、どのオブジェクトの責務でしょうか。

単独のオブジェクトの責務とする場合もあれば、複数のオブジェクトの相互作用とする場合もあるでしょう。

例えば、

(1) 倉庫クラスの静的メソッドとします。

     Warehouse#transferStock(倉庫1, 倉庫2, 商品, 数量)

(2) 倉庫クラスのインスタンスメソッドとします。

     warehouse.transferStock(別の倉庫, 商品, 数量)

などが考えられます。

しかし、ある責務を、あるエンティティオブジェクトや値オブジェクトの責務とすると、不自然な場合があります。

このようなときには、サービスオブジェクトを検討します。

そうして、次のように設計してみます。

(3) 倉庫サービスの倉庫間移動

     StockService#transferStock(倉庫1, 倉庫2, 商品, 数量)

サービスオブジェクトを適切に追加することで、適切な責務割当てを実現できる場合があります。

サービスオブジェクトは、デザインパターンのファサード (Facade) としての役割もあります。

但し、色々な責務をサービスに詰め込んでしまうと、アンチパターンと同類になってしまうので、注意してください。

まずは、適切なエンティティや値オブジェクトを検討します。

例として、平面に図形描画する処理系を実現する場合を考えてみます。

円や矩形の描画処理は、どのように設計・実装すべきでしょうか。

ケース(1)

DrawingService.drawCircle(x, y, radius);

DrawingService.drawRectangle(x, y, width, height, angle);

ケース(2)

Circle circle = new Circle(x, y, radius);

circle.draw();

Rectangle rectangle = new Rectangle(x, y, width, height, angle);

rectangle.draw();

ケース(1)の場合、DrawingServiceはすぐに肥大化し、役割は不明瞭になるでしょう。

ケース(2)の方が適切でしょう。

なお、ここでは、在庫管理業務や描画処理系そのものについては議論していません。

業種や組織によっても最適なドメインモデルは違うでしょう。

モジュール

ドメイン駆動設計のモジュールという概念は、Javaのパッケージと同義です。

モジュール名もユビキタス言語に含まれる名前です。

モジュール名、モジュール構成もリファクタリングの対象です。

モジュール間は低結合、モジュール内は高凝集にします。

集約

集約を見つけ出し適切にモデリングすることは深い問題です。

※引用：ここから (DDD本 p.123)

関係を最小限に抑えるように設計することにより、 関連を辿る処理は単純化され、 関係性の爆発的増加もある程度は制限される。 しかし、ほとんどのビジネスドメインは非常に強く相互に結びついているので、 結局はオブジェクトの参照を通じて、長くて深い経路を辿ることになる。 ある意味で、こうしたもつれはこの世界の現実を反映している。 現実には、はっきりした境界が引いてもらえることはめったにないのだ。 これはソフトウェアの設計における問題である。

※引用：ここまで (DDD本 p.123)

次図は集約の例です。ドメインとしては架空の書店の書籍情報管理を想定しています。

もし、出版社の業務であれば、集約ルートとしては、書籍よりもISBNの方が適切かもしれません。

(DDD本の「境界づけられたコンテキスト」も参考になります)

実際の開発では、必要なユースケースを実行できるように、リファクタリングと検証を繰り返しながら、ドメインモデルを作り上げていきます。

価格やISBNは、使用するプログラミング言語の数値型や文字列型で十分な場合もありますが、ドメインモデルに価格クラスやISBNクラスを追加することで、より洗練された分かり易いモデルになることもあります。

 ・集約ルートエンティティはグローバルな同一性を持ちます。

 ・境界内部のエンティティは境界内でのみ一意となるローカルな同一性を持ちます。

 ・境界外にあるオブジェクトは、ルートエンティティへの参照を保持できます。

 ・境界外にあるオブジェクトは、境界内部への参照を保持することはできません。集約ルートを介して参照します。

オブジェクト指向

ドメイン駆動設計において、オブジェクト指向モデリングやオブジェクト指向プログラミングは必須ではありません。

しかし、モデリング手法としての実績や、モデル駆動開発との相性を考えると、必須のパラダイムと言えます。

もちろん、ドメインモデル以外のビュー層やインフラストラクチャ層などにも適用します。

モデル駆動

モデル駆動開発 (Model-Driven Development, MDD) は、 OMG (Object Management Group) が提唱するモデル駆動アーキテクチャ (Model-Driven Architecture, MDA) に則ったソフトウェア開発手法です。

MDDでは、分析・設計・実装・テストといった開発の成果をモデルとして作成し、 モデル変換を繰り返すことでアプリケーションを開発 (実装ソースコードを自動生成) する手法です。

ただし、ドメイン駆動設計では、分析モデルと設計モデルといった分け方はしません。

ドメイン駆動設計では、唯一のモデルを作成します。

例えば、分析モデルと設計モデルを分けて作成すると、担当者や工程でモデルが分離されたり、実装と乖離してしまうことがあります。

ドメイン駆動設計では、このような分断を避けるために、1つのモデルだけを作成します。

アジャイル手法

ドメイン駆動設計では、イテレーティブな開発が基本です。

ウォータフォール的な発想や計画では、ドメイン駆動設計は成功しないでしょう。

また、最初から多くのプラクティスやパターンを取り入れようとすると失敗するでしょう。

パターンやプラクティスを段階的に取り入れながら、ドメインモデルを高度化し深化させていく、アジャイルな開発スタイルが必要です。

同様に、ドメイン駆動設計スキルも段階的に向上させていければよいわけです。

※ 本記事では、アジャイル開発とイテレーティブ開発、反復型開発を区別しないで混用します。

アナリシスパターン

マーチン・ファウラー氏の著書「アナリシスパターン」には、再利用可能なオブジェクトモデルがパターンとして示されています。

これらのオブジェクトモデルは、例題となった業務 (ドメイン) だけでなく、他のドメインにも適用できるものです。

そのまま適用できなかったとしても、ドメインモデルを作成するときの貴重な手本になるでしょう。

アナリシスパターンで示されているパターンは、よく洗練されたものであり、深いモデルです。

時として、深すぎて難しく感じるものもありますが、とても有益なヒントになります。

デザインパターン

GoFと呼ばれる4人による共著「オブジェクト指向における再利用のためのデザインパターン」では、 オブジェクト指向設計、実装に関する23個のパターンを示しています。 各パターンは主に次の4つに分類されます。

(1) 生成に関するパターン

(2) 構造に関するパターン

(3) 振る舞いに関するパターン

(4) マルチスレッドプログラミングに関するパターン

実装の観点からの設計パターンです。

ドメイン駆動設計のドメインモデルを作成する際や、リファクタリングする際に参考になります。

GoFとは、エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人です。

Naked Objects パターン

ここで、ドメイン駆動設計に通じるコンセプトを持つ Naked Objects パターンを紹介します。

Naked Objects パターンでは、ドメイン駆動設計と同様に、ドメインモデルを中心に置きます。

アプリケーションを開発する時には、ドメインオブジェクトだけを作成します。

ユーザインタフェース層やデータアクセス層は、ドメインオブジェクトから自動で作成します。

十分に洗練され深化したドメインモデルがあれば、 ドメインモデルの各インタフェースをビューとしてユーザに公開するだけで、アプリケーションとして機能する、という考えです。

ドメインモデルの各インタフェースとは、サービスやクラスのメソッド、プロパティのことです。

ビューは、画面のことです。

「Naked Objects for .NET - 生産性の高い.NETフレームワーク- InfoQ」から引用します。

※引用：ここから

ユーザインタフェースのレイヤやデータアクセスのレイヤを書く必要がないだけでなく、naked objectsパターンは良いオブジェクトモデリングも促します。

なぜならドメインモデルのプロトタイプを直ちにエンドユーザが評価できるアプリケーションにすることができるからです。

これらのことを聞いた時にほとんどの人は、大規模で複雑なビジネスアプリケーションではおそらく有効でないだろう、という反応を示します。

※引用：ここまで

引用元のサイトでは、大規模アプリケーションの事例が紹介されています。

なお、本記事で紹介しました「自動生成ツール DDBuilder」は、 Naked Objects パターンにインスパイア (触発) されたものです。

CRC

CRC (Class Responsibility Collaborator)

ドメイン駆動設計とは直接関係しませんが、オブジェクト指向分析ツールにCRCカードがあります。

もしも、ドメインオブジェクトの見つけ方で悩まれているならば、CRCカードを使ってみる価値があると思います。

反復型開発

反復型開発は、段階的にソフトウェアの完成度を上げていく手法です。

反復する単位をイテレーションと呼びます。

１回のイテレーションで、分析から設計、実装、検証までを行います。(ミニウォーターフォール)

ドメイン駆動設計では、ドメインモデル、実装、ユビキタス言語の３つを、常に整合させながら繰り返し洗練します。

[反復型開発の流れ]

※ 本記事では、イテレーティブ開発、インクリメンタル開発、アジャイル開発を含めて反復型開発と表記します。

実装モデル

実装モデルは、ソフトウェアで表現された実行可能なモデルです。

例えば、ドメインモデルを含んだWebアプリケーションは、実装モデルです。

テストドライバーからドメインモデルを動かすような実装モデルも考えられます。

実装モデルは、次の点で必要です。

• 実装モデル は、各イテレーションの成果物のひとつです。
• 実際に動かすことで、ドメインモデルをより正確に検証できます。
• 具体的に動かすことで、開発チーム内でのドメインモデルに対する知識や理解のバラつきを抑止します。
• 過剰な分析や議論の空回り状態を予防します。
• 技術寄りではないメンバーも、具体的な動きをみることで検証しやすくなります。

モデル図や単体テストレベルのテストコードだけで検証しようとすると、手間がかかり、検証の精度も上がりません。

しかし、動作可能なアプリケーションなどがあれば、UML図などに不慣れなメンバーでも、検証作業が容易になり、精度も上がります。

ただし、イテレーションを繰り返しながら、実装モデルを動くように維持することは、手間がかかります。

なぜなら、ドメインモデルをリファクタリングすると、Webアプリケーションであれば、そのビュー層や永続化層、あるいは、テストドライバに変更が必要になるからです。

そこで本記事では、イテレーションを軽量化するために、次のようなツールを活用します。

自動生成ツールの活用

Java ドメインモデルから、Java Web アプリケーションを自動生成するツール (後述) を活用します。

自動生成することで、ドメインモデル以外の "本質ではない作業" が軽減されて、イテレーションサイクルも短くなります。

下図は、その流れ図です。

イテレーションの流れ

自動生成処理の流れ

より詳細はユーザーガイド(PDF)を参照ください。

自動生成の効果

ドメインモデルからアプリケーションを自動生成すると、次のような効果が期待できます。

• 継続的なビルド＆テスト
• 開発の早い段階からのテスト
• イテレーションの軽量化
• イテレーションの質の向上
• コードファースト
• モデルと実装の一致
• 永続化周りの煩雑なコードの削減
• 手組み実装によるミスとロスの排除

自動生成の成果物

ここで、本当の目的は、アプリケーションの生成ではなくて、検証されたドメインモデルです。

開発チームは、自動生成された Java Web アプリケーションに縛られる必要はありません。

ドメインモデルは 自動生成ツールには依存しません。

ドメインモデルは 他の Webアプリケーションやデスクトップアプリケーションのドメイン層に移植できます。

もちろん、自動生成されたものをそのまま Webアプリケーションとして実運用することもできます。

自作のページも追加できます。(再度自動生成しても追加したページは上書きされません)

次のセクションで、このツールについて説明します。

機能

Java で実装されたドメインモデルから、Java Web アプリケーションを生成します。

入力は、Java で実装されたドメインモデル、

出力は、Java Webアプリケーションです。

ドメインモデルの例

ドメインとして、簡単な「在庫管理業務」を考えます。

ドメインモデルには、4つのクラスが存在しているものとします。

以下に、クラス名の一覧、クラス図、Java実装コードを示します。

なお、DDBuilderにとって必要な情報は、Java実装コードだけです。

(クラス名一覧)

倉庫クラス : Warehouse

在庫クラス : Stock

製品クラス : Product

在庫サービスクラス : StockService

(クラス図)

(Java 実装例)

package mycom.domain;
import java.util.List;
import javax.persistence.Entity;
import javax.persistence.OneToMany;
import mycom.domain.ddb.DdBaseEntity;
/**
 * 製品
 */
@Entity
public class Product extends DdBaseEntity {

    /** 製品名 */
    private String name;
    
    /** 在庫リスト */
    @OneToMany(mappedBy="product")
    private List<Stock> stockList;
    
    /** コンストラクタ */
    public Product() {
        super();
        this.name = "";
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public List<Stock> getStockList() {
        return stockList;
    }

    public void setStockList(List<Stock> stockList) {
        this.stockList = stockList;
    }
    
    @Override
    public String getDDBEntityTitle() {
        return "タイトル: " + this.getName();
    }
}
[4つのクラスを全て表示]

なお、このドメインモデルは、自動生成機能を説明するためのものです。

そのため、ドメインモデルらしい振る舞い等は含んでいません。つまり、ドメインモデル貧血の状態であることに注意してください。

生成されたWebアプリケーションの画面

DDBuilderは、Java実装コードを読み込み、Webアプリケーションとして必要な、ビュー層や永続化層を生成します。

生成結果は、1つのフォルダに出力され、そのフォルダは、そのまま Eclipse にインポートできます。

つまり、出力フォルダは「Eclipse 動的 Web プロジェクト」の構成になっています。

下図は、出力フォルダの内容です。

.settings, .classpath, .project は Eclipse の設定ファイルです。

src フォルダ配下に、domain, persistence, service, viewパッケージフォルダがあります。

lib フォルダの配下には、必要な OSS のライブラリが含まれています。

ロックインフリー

開発チームは、DDBuilderにロックインされる (しばられる) ことはありません。

いつでもDDBuilderを切り離すことができます。

切り離した後は、WicketとHibernateを使ったシンプルな Java Webアプリケーションとして開発や保守を継続できます。

あるいは、ドメインモデル層とサービス層を他のアプリケーションフレームワークに移植することもあるでしょう。

Java

Java は、強い静的型付けのオブジェクト指向言語です。

DDBuilder では、ドメインモデルの実装言語は Java です。

自動生成されるアプリケーションも Java Webアプリケーションです。

Java は静的型付け言語なので、Eclipseなどのリファクタリング機能を使って安全に変更できます。

また、ドメインモデルを他の言語や他のフレームワークへ移植する場合にも、元の言語が Java であれば、より安全に移植できるでしょう。

Apache Wicket

自動生成されるアプリケーションのビュー層には、Wicketを使用します。

Wicketは、ビュー層を担う Java Web アプリケーションフレームワークです。

Struts系と違い、 オブジェクト指向プログラミングモデルを前提としたフレームワークです。

HTMLとの独立性が高く、基本的にすべてをJavaコードで実装します。

開発者が Wicketを意識するのは、自作ページを追加するときです。

Java EE JPA

自動生成されるアプリケーションの永続化層には、Hibernateを使用します。

Hibernateは、JavaEE JPA実装の1つです。

自動生成されるアプリケーションでは、特に指定がなければ、データベースとして、Java標準の JavaDB を使用します。

ただし、Hibernateは、PostgreSQL, MySQL, Oracle, SQLServer, DB2などの代表的なDBMSをサポートしており、DDBuilderの場合も、設定ファイルを変更するだけで DBMS を変更できます。

ドメインモデル層のクラスを実装するときには、JPA / Hibernate の知識が必要になります。

主に、関連を定義するためのアノテーションの書き方などの知識が必要になります。

自動生成されるクラス

DDBuilder利用者が実装するドメインクラス (エンティティ) と、DDBuilderが自動生成するクラスについて説明します。

例として、開発者が Product.javaというドメインクラス (黄色の網掛けのクラス) を作成したとします。

次に、DDBuilderで自動生成を実行すると、下図ようなクラスとHTMLファイルが自動生成されます。(下図は、すべてではなく、主なファイルです)

view, service, domain, persistenceはパッケージ名です。

それぞれ、ビュー層、サービス層、ドメイン層、永続化層に相当します。

開発者が Product.javaを実装すれば、ビュー層、永続化層のクラスは自動的に生成されます。

自動生成されたものは、そのまま Java Web アプリケーションとして動作します。

Productの登録、更新、削除、一覧がWeb画面で操作できます。

ビュー層の1つの画面は、同名のHTMLファイルとJavaクラスで構成されます。

例: ProductPage.htmlとProductPage.java。

これは、ビュー層で使用している Apache Wicket フレームワークの仕様です。

Wicketは、JSP/Struts系のアーキテクチャではなく、Jave EE JSF 系のアーキテクチャです。

HTMLファイルは独立しており、通常のHTMLと同様に編集できます。

つまり、JavaやJSPなどの知識が不要なので、デザイン専門の方でも編集できます。

Wicketでは、画面は、完全に Java オブジェクト指向プログラミングで実装できます。

例えば、Productを使用するサービスが必要になった場合は、上図のSomeService.javaのように追加できます。

もちろん、サービス名は適切な名前を付けます。数は制約されません。

自動生成された画面だけでは不足する場合は、画面を追加できます。(上図では、CustomePage)

自動生成を再度実行しても、SomeServiceやCustomePageは上書きされません。

詳しくは、「DDBuilderを使った開発の流れ」を参照ください。

自作ページの追加

自動生成されたWebアプリケーションに自作のページを追加できます。

DDBuilderは、自作ページを上書きしません。

ページを自作する場合には、自動生成されたコードが参考になりますが、より洗練されたページの例も本サイト内で公開しています。

・ページサンプル : Wicket DataTable ソート列 アクション列 テーブル

・ページサンプル : 改ページ付き・ソート列付き・1件複数行対応 テーブル

トランザクション管理

次ドメイン駆動設計されたアプリケーションでは、Java EE JPA の永続化コンテキスト (EntityManager) を使用してトランザクション管理を行います。

JPA の仕様としては、永続化コンテキストには、次の2種類があります。

(1) コンテナ管理

永続化コンテキストのライフサイクル (生成、破棄) は、EJBコンテナによって管理されます。

(2) アプリケーション管理

永続化コンテキストのライフサイクルは、アプリケーションによって管理されます。

EJBコンテナは必要ありません。

DDBuilderが生成するアプリケーションでは、(2)のアプリケーション管理を使用します。

従って、特別なコンテナを必要としません。

永続化コンテキストのライフサイクルは、自動生成されたコードによって行われます。

DDBuilder利用者は、特に意識する必要はありません。

トランザクションを管理するためには、トランザクションマネージャを使用します。

トランザクションマネージャには、次の2種類があります。

(1) JTAトランザクション

EJBコンテナが必要です。トランザクション管理は、EJBコンテナによって自動的に行われます。

(2) リソースローカルトランザクション

EJBコンテナは必要ありません。

DDBuilderが生成するアプリケーションでは、(2)のリソースローカルトランザクションを使用します。

従って、特別なコンテナを必要としません。

トランザクション管理は、自動生成されたコードによって行われます。

DDBuilder利用者は、特に意識する必要はありません。

永続化コンテキストのライフサイクル、トランザクション管理の流れを下図に示します。

クラス図の扱い

DDBuilderにはクラス図をサポートする機能はありません。

しかし、ドメイン駆動設計を実践するうえで、クラス図やそれに相当するものは重要です。

本記事では、分析時のクラス図は手書きのラフスケッチという位置づけです。

そして、最終的なクラス図は、UMLツールなどで Java ソースからリバースエンジニアリングされることを推奨します。

リバースエンジニアリングであれば常に実装と一致させることができます。

関連のタイプと属性型

このセクションでは、DDBuilderがサポートする関連の種類、インスタンス属性型の種類を示します。

そのため、サンプルのモデルには、ドメイン駆動設計のエンティティらしいメソッドが無いことに注意してください。

また、この例では、エンティティ間の関連をJPAアノテーションを使って実装していますが、必須ではありません。

実際のドメインモデリングでは、関連を決めることが大変難しい業務や局面があります。

関連を確実に定義できるところは、この例のように実装して、

あいまいさが残る部分は、JPQLやネイティブSQLを使って、関連を実装することも検討すべきです。

[サンプルコードをダウンロード]

UMLクラス図

サンプル コードには次の5つのクラスが含まれています。

(1) 著者 @Entity

public class Author extends DdBaseEntity

(2) 書籍 @Entity

public class Book extends DdBaseEntity

(3) 版 @Entity

public class Edition extends DdBaseEntity

(4) ISBN @Entity

public class Isbn extends DdBaseEntity

(5) 書店 @Entity

public class Store extends DdBaseEntity

関連タイプと属性型の Java サンプルコード

/*
 * DDBuilderで使える関連タイプと属性型に関する例です。ドメイン駆動設計的な観点の例ではありません。
 */
package jp.co.nextdesign.domain;
import java.util.ArrayList;
import java.util.List;
import javax.persistence.CascadeType;
import javax.persistence.Entity;
import javax.persistence.OneToMany;
import javax.persistence.Transient;
import jp.co.nextdesign.domain.ddb.DdBaseEntity;

/**
 * 著者
 */
@Entity
public class Author extends DdBaseEntity {
    private static final long serialVersionUID = 1L;

    /** 名前 */
    private String name;
    
    /** 書籍リスト owning/parent */
    @OneToMany(mappedBy="author", cascade=CascadeType.ALL, orphanRemoval=true)
    private List<Book> bookList;

    /** 書籍リスト owning/parent */
    @OneToMany(mappedBy="author2", cascade=CascadeType.ALL, orphanRemoval=true)
    private List<Book> bookList2;

    /** コンストラクタ */
    public Author(){
        super();
        this.name = "---";
        this.bookList = new ArrayList<Book>();
        this.bookList2 = new ArrayList<Book>();
    }
    
    //OneToManyで双方向関連を維持するためのコードを含むgetBookList(),
    //setBookList(List<Book> bookList)の例
    @Transient
    private ArrayList<Book> latestBookList = new ArrayList<Book>();
    public List<Book> getBookList() {
        return this.bookList;
    }
    public void setBookList(List<Book> bookList) {
        for(Book newBook : bookList){
            if (!latestBookList.contains(newBook)){
                newBook.setAuthor(this);
            }
        }
        for(Book oldBook : latestBookList){
            if (!bookList.contains(oldBook)){
                oldBook.setAuthor(null);
            }
        }
        this.bookList = bookList;
        latestBookList = new ArrayList<Book>(this.bookList);
    }

    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public List<Book> getBookList2() {
        return bookList2;
    }
    public void setBookList2(List<Book> bookList2) {
        this.bookList2 = bookList2;
    }
    
    @Override
    public String getDDBEntityTitle(){
        return this.name;
    }
    
    /** debug */
    public String getDebugInfo(){
        String info = "<" + this.getClass().getSimpleName() + ">";
        info += "\nname=" + this.getName();
        info += "\n</" + this.getClass().getSimpleName() + ">";
        return info;
    }
}
[すべてのクラスを表示]

【注意】

この例は、DDBuilderがサポートする属性型と関連の型を示すためのものです。

そのため、ドメインモデルとしての重要な責務 (メソッド) が欠けています。

【注意】

このサンプルモデルはシンプルですが、現実には、集約 (AGGREGATES) についても注意深くモデリングする必要があります。

ただし、JPAのアノテーションを使って、すべての関連を実現しようとしないことです。

※引用：ここから (DDD本 p.123)

関係を最小限に抑えるように設計することにより、 関連を辿る処理は単純化され、 関係性の爆発的増加もある程度は制限される。

しかし、ほとんどのビジネスドメインは非常に強く相互に結びついているので、 結局はオブジェクトの参照を通じて、長くて深い経路を辿ることになる。

ある意味で、こうしたもつれはこの世界の現実を反映している。

現実には、はっきりした境界が引いてもらえることはめったにないのだ。

これはソフトウェアの設計における問題である。

※引用：ここまで (DDD本 p.123)

DDBuilderを使った開発の流れ

ツールのダウンロード

動作確認済みの環境

• Java 8
• Windows7 pro 32bit/64bit, Windows10 pro 64bit
• Eclipse IDE for Java EE Developers 4.4, 4.3
• Apache Tomcat 7.0, 8.0, 8.5, 9.0

インストールとアンインストール

インストールやアンインストールは不要です。

ダウンロードしたzipファイルを適当な場所に解凍してください。

不要になった場合は、 それらをエクスプローラなどで削除してください。

※ ダウンロードしたファイルを解凍すると、次の説明ファイルが含まれています。

「はじめにお読みください(使い方).txt」

「DDBuilder_Guide_Ver2.pdf」

ダウンロードページへ

ユーザガイド

ユーザガイド [PDF] [2.5MB]

サポート

使いはじめ等で、ご不明な点がありましたら「お問合せフォーム」からご連絡ください。 (無料)

弊社の都合で返信が遅くなる場合がありますが、ご了承ください。

また、有料でのサポートも別途用意しております。詳しくはお問合せください。

オープンソースで公開

GiHubでオープンソースとして公開しています。 [Apache License Version 2.0]

- DDBuilder (ツール本体)

https://github.com/nextdesign-co-jp/DDBuilder.git

- DDBuildertemplate (テンプレート)

https://github.com/nextdesign-co-jp/DDBuilderTemplate.git

オープンソースソフトウェアへの謝辞

DDBuilderは次のソフトウェアを利用しています。

• Apache Wicket 7.4.0
• hibernate-entitymanager4.3.6.Final
• Derby10.10.2.0
• log4j2.5
• Eclipse jdt3.9.1