ドメイン駆動設計の基本的な指針とドメイン中心開発の流れ

オブジェクト指向でドメインモデリング

ドメイン駆動設計のドメインモデリングを行うために、必ずしもオブジェクト指向モデリングを使う必要はありません。

しかし、これまでの実績やモデル駆動開発との相性を考えると、今のところ、オブジェクト指向技術が最適と言えます。

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

ドメイン駆動設計では、オブジェクト指向技術は必要な技術です。

モデル駆動で反復型開発

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

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

ドメイン駆動設計の反復型開発においても、MDDの考え方に従います。

ただし、ドメイン駆動設計では、モデルを「分析モデル」や「設計モデル」等に分けません。

つまり、ドメイン駆動設計では、参照するモデルはただ一つとします。

例えば、担当者や工程でモデルを分離すると、追跡可能性が失われたり、実装と乖離してしまうことがあります。

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

アジャイル手法で反復型開発

ドメイン駆動設計では、アジャイル手法に則った反復型開発が基本です。

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

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

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

そうすれば、ドメイン駆動設計のスキルも段階的に向上できます。

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

アナリシスパターンはドメインモデリングのヒント

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

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

ドメイン駆動設計のドメインモデリングにおいて、参考になるでしょう。

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

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

デザインパターンは実装のヒント

書籍「オブジェクト指向における再利用のためのデザインパターン」には、オブジェクト指向設計、実装に関する23個のパターンが記載されています。

各パターンは主に次の4つに分類されます。

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

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

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

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

ドメイン駆動設計のドメインモデルを実装する際や、リファクタリングする際に参考になるでしょう。

もちろん、ドメイン層以外の層でも役立ちます。

書籍「オブジェクト指向における再利用のためのデザインパターン」は、エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4共著です。この4人はGoFと呼ばれます。

Naked Objects パターンには多くの共通点

Naked Objects パターンは、ドメイン駆動設計に通じるコンセプトを持っています。

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

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

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

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

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

本記事で紹介する「DDBuilder」は、 Naked Objects パターンにインスパイア (触発) されたものです。

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

※引用：ここから

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

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

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

※引用：ここまで

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

CRCでモデリングの練習

オブジェクト指向分析ツールにCRCカード (Class Responsibility Collaborator) というものがあります。

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

ドメインモデルの役割

アプリケーションの本質はドメインです。

画面のデザインや永続化の仕組みなどは、本質ではありません。

ドメインに存在する本質的な振る舞いはすべて、ドメインモデルの役割です。

ドメイン駆動設計によるアプリケーション開発において、ドメインモデルはアプリケーションの土台であり、開発の中心軸となります。

ドメインモデル中心の反復型開発

ドメイン駆動設計では、反復型開発が基本です。

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

開発者はドメインモデルを繰り返しリファクタリングすることで、ドメインモデルの完成度を上げていきます。

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

各イテレーションの中では、分析から設計、実装、検証までを完結させます。

そのため、イテレーションは、ミニウォーターフォールとも言われます。

また、ドメイン駆動設計では、ドメインモデル、実装、ユビキタス言語の３つを整合させながら反復することが重要です。

(反復型開発は、イテレーティブ開発やインクリメンタル開発、アジャイル開発などと似ていますが、本記事では、特に区別しません)

[反復型開発の流れ]

イテレーションの流れ

下図は、1回のイテレーションの流れです。

開発チームは、下図のような作業を繰り返します。

開発チームによって多少の違いはありますが、大筋は同じでしょう。

まず、開発チームは、ドメインモデリングを行い、ドメインモデルを実装します。

次に、動くソフトウェアモデル (ここでは、Webアプリケーション) に必要なプレゼンテーション層や永続化層を実装します。

最後に、Webアプリケーションを起動して、ドメインモデルの振る舞いを検証します。

期待通りの振る舞いを確認できれば、次のイテレーションに着手します。

実装モデル

実装モデルとは、動くソフトウェアモデル。(ソフトウェアで表現された「動くモデル」)

ドメインモデルの実装 (例:ドメイン層) と、ドメインモデルを動かすための実装 (例: ビュー層や永続化層) を含んだものです。

ドメインモデルを動かすための方法は色々考えられます。

例えば、Webアプリケーションのドメイン層にドメインモデルを置いて動かす方法です。

あるいは、テストドライバーからドメインモデルを動かすような方法も考えられます。

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

・実装モデル は、各イテレーションの成果物のひとつです。

・実際に動かすことで、ドメインモデルをより正確に検証できます。

・具体的に動かすことで、ドメインとドメインモデルについての、開発チーム内での知識や理解のバラつきを小さくします。

・ドメインモデリングに関する過剰な分析や議論の空回りを予防します。

・技術寄りではないメンバーでも検証しやすくなります。

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

動作可能な実装モデルがあれば、UML図などに不慣れなメンバーでも、検証作業が容易になり、精度も上がります。

アプリケーション自動生成の利点

イテレーションの主要なタスクは、ドメインモデリングです。

ドメインモデリングをスムーズに繰り返すためには、ドメインモデルを素早く検証できる仕組みが必要です。

ドメインモデルを検証するためには、「動くソフトウェアモデル」を使う方法が最適です。

しかし、イテレーションを繰り返しながら、「動くソフトウェアモデル」を保守することは大変です。

それは、ドメインモデルをリファクタリングすると、メインモデル以外の実装にも変更が必要になるからです。

例えば、「動くソフトウェアモデル」が Webアプリケーション型であれば、ビュー層や永続化層にも変更が必要です。

これらの変更作業は、単純で面倒な作業です。

そのため、イテレーションサイクルは長くなり、開発者はドメインモデリングに集中できなくなります。

イテレーションの作業負荷が大きくなって、反復できなくなるケースもあります。

もし、ドメインモデルからアプリケーションを自動生成できれば、このような本質的ではない作業を軽減できます。

その結果、開発者はドメインモデリングに集中できるようになります。

ドメイン駆動設計を効果的に実践するためには、軽量なイテレーションの仕組みが必要です。

DDBuilder

DDBuilderは、ドメイン駆動設計のドメインモデルからJava Webアプリケーションを自動生成します。

当社が開発し公開している無料・無保証のソフトウェアツールです。

ダウンロード...

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

[動作確認済みの環境]

・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」

[サポート]

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

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

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

[オープンソースで公開]

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

- DDBuilder (ツール本体)

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

- DDBuildertemplate (テンプレート)

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

[OSSへの謝辞]

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

・Apache Wicket 7.4.0

・hibernate-entitymanager4.3.6.Final

・Derby10.10.2.0

・log4j2.5

・Eclipse jdt3.9.1

自動生成の流れ

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

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

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

(クラス名)

倉庫クラス : Warehouse

在庫クラス : Stock

製品クラス : Product

在庫サービスクラス : StockService

(クラス図)

(Java 実装例)

Javaコードを表示する...

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

そのため、ドメインモデルらしい振る舞い等は含んでいません。

つまり、ドメインモデル貧血の状態であることに注意してください。

自動生成の結果

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

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

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

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

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

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

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

Webアプリケーションの画面例

EclipseにインポートしたWebアプリケーションを起動します。

以下は、そのWebアプリケーションに、Chromeブラウザからアクセスした時の画面です。

[ホーム画面]

http://localhost:8080/myapp/ にアクセスします。(myapp は DDBuilderの操作画面で指定したアプリケーションの名前です)

ホーム画面として、3つのボタンを持つ画面が表示されます。

なお、Eclipseへのインポートや起動方法の詳細は「開発の流れ」を参照してください。

自動生成されるWebアプリケーションのレイヤ構成

下図は、DDBuilderが自動生成する Java Web アプリケーションの構成図です。

DDD本 (p.70) のレイヤ化アーキテクチャに準じています。

次のオープンソースソフトウェアを使用しています。

・ビュー層：Apache Wicket

・永続化層 (インフラストラクチャ層)：Java EE JPA / Hibernate

自動生成されるクラス

開発者が実装するドメインクラス (エンティティ) と、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を使った開発の流れ」を参照ください。

使用できる関連のタイプと属性型

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

この例では、JPAアノテーションを使って、エンティティ間の関連を定義しています。

ただし、必ずしも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のアノテーションを使って、すべての関連を実現しようとしないことです。

JPQLやネイティブSQLを使って、関連を実装することも検討すべきです。

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

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

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

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

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

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

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

自作ページの追加

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

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

ページを自作する場合には、自動生成されたコードが参考になるはずです。

より複雑なページの例も本サイト内で公開しています。

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

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

クラス図の扱い

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

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

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

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

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

ツールへのロックインなし

開発チームは、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が自動生成したWebアプリケーションでも、設定ファイルを変更するだけでDBMSを変更できます。

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

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

トランザクション管理

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

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

[永続化コンテキストの種類]

(1) コンテナ管理

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

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

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

DDBuilderが生成するアプリケーションでは、(2)のアプリケーション管理を使用しますので、特別なコンテナを必要としません。

永続化コンテキストのライフサイクルは、自動生成されたコードによって行われますので、DDBuilder利用者は、特に意識する必要はありません。

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

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

[トランザクションマネージャの種類]

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

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

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

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

DDBuilderが生成するアプリケーションでは、(2)のリソースローカルトランザクションを使用しますので、特別なコンテナを必要としません。

トランザクション管理は、自動生成されたコードによって行われますので、DDBuilder利用者は、特に意識する必要はありません。

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

ドメイン駆動設計の入門者の学習をサポート

DDBuilderは、開発時だけではなく、ドメイン駆動設計の入門者の学習にも役立ちます。

学習のためにドメインモデルを作成しても、ドメインモデルを動かすまでに時間がかかってしまい、ドメイン駆動設計に集中できなくなることがあります。

しかし、DDBuilderを活用すれば、簡単に、動かしてみることができます。

実際にドメインモデルを実装して、具体的に動かしてみれば、ドメインモデルの役割や位置づけが理解しやすくなります。

机上だけで、ドメイン駆動設計やドメインモデルを理解することは、簡単ではありません。

ドメインがアプリケーションの本質であるという考え方や、ドメインモデルを中心にした開発方法、イテレーティブな開発についても理解しやすくなるでしょう。