c＃実装から見るddd(ドメイン駆動設計)

わんくま同盟大阪勉強会 #60

C#実装から見る

DDD（ドメイン駆動設計）Ver2.0 （ちょっと追記版）

By @kawakawa


はじめに

みなさん、

DDDをご存じでしょうか？


はじめに

DDDとは、2011年に日本で出版された「ドメイン駆動設計」の事です。


はじめに

DDDは書籍以外にも、ネット上に多数の資料があり、目にされた方も多いかと思います。


はじめに

しかし、DDDは理屈の理解はできても、

実践するのは、難しいと思います。

まず、

顧客（ドメインエキスパート）が要ります。

仲間（開発チーム）が要ります。

プログラム知識が要ります。

・・・・


はじめに

本日は、DDDをプログラム実装という

観点から見てみることで、

DDDを知らない人には、興味のキッカケを、

DDDの実装をしらない人には、一例を提示できればと思いました。

それではみなさん、よろしくお願いします。


自己紹介

• かわべたくや

• Twitter：@kawakawa

• 大阪で働いています

• I Love C#！

• DDD勉強中！


はじめに

DDDを知らなくても、困らないような資料にしたつもりですが、やっぱり知らないより、知っていたほうが楽しいので、簡単にDDD

を説明させて頂きます。


DDD知らない方向け

「DDDとは？」（独断と偏見で説明）


DDDとは？

• DDDとは、「Domain-Driven-Design」

• 訳すと、「ドメイン駆動設計」

• よく目にする、●DD「●-Driven-

Development」は、「●駆動“開発”」であり、「●駆動“設計”」と異なります。


DDDとは？

• ドメインとは、「領域」の意味。

（顧客のお仕事＝「業務領域」であり、これも１つのドメインです）

• ドメインから問題・関心ごとを抜き出したのが「（ドメイン）モデル」。

• プログラマのお仕事は、この「モデル」をプログラムで実装することです。


DDDとは？

• 開発は、モデルを「分析」「設計」「実装」のサイクルをグルグル回します。

（モデル駆動開発と呼ばれてます）

• ドメイン駆動“設計”とは、そのグルグル回すことを如何に継続させるか設計することです。


DDDとは？

• よくある勘違いとしては、DDD本自体にモデルの答えは書いていません。（モデリングの本ではないです）

• モデリングを継続させる方法を考える本です。

（魚をくれるのではなく、釣り方を教えてくれる本）


DDDを行う意義とは？


DDDの意義

私が思うDDDの意義は、

・DDD本を読むまで

「動くアプリが正義！」

・DDD本を読んだ後

「動き続けるアプリが正義！」

アプリへの認識が変わりました。（※動く=顧客の問題を解決すると読み替えてもOK）

（※動く≒顧客の問題を解決する）


DDDの意義

動き続けるとは？

• 業務システムで考えると、納品は、開発の終わりではありません。納品してからも開発は続きます。

（有償・無償は問わず）

• 顧客から要望は色々出てきます。

「より見やすい画面が欲しい」

「より操作しやすくして欲しい」

• 顧客の業務形態に変化が生ずれば、仕様変更です。


DDDの意義

つまり、動き続けるとは、

変化し続けるという事。

どこまで、仕様変更に追随できますか？


DDDの意義

つまり、動き続けるとは、

変化し続けるという事。

どこまで、仕様変更に追随できますか？

※勿論、業務形態が根本的に変化したのなら、追随は無理です。（不動産屋が八百屋にジョブチェンジなど）


DDDの意義

また、DDDに向かない場合もあります。

• ドメインが薄い

（DDD行うほうが労力かかります）

• アプリの使用期間が短い

（一度きりで再利用しない場合。デモアプリなど）


DDDの面白い所


DDDの面白い所

DDDでは、モデルは実装されて初めて意味を成すと考えられています。

つまり、図やUMLがモデルではなく、動くソフトウェアまで含めて、モデルと考えられています。


DDDの面白い所

プログラミングにおいて大抵は、実装上の制約（性能や品質等々）により、設計図通りに実装出来ないものですが、そう言った点も含めて、絵にかいた餅ではなく、動くモデルに注力しているのが、非常に現実的で、DDDは面白い思想だと思いました。


それでは、DDDの実装を見てみましょう


とその前に・・・

いきなりですが、DDDは実装も大事ですが、実装以外の項目も大事です。

• 顧客（ドメインエキスパート）とのコミュニケーション

• コンテンツマップ作成

• ユビキタス言語の発見

• 開発チームづくり・・・などなど。

残念ながら、実装だけ見ても“DDD”はできません…。


DDD実装のサンプル元

• 実装サンプルは、DDD本：著者エヴァンスも関わった「DDD

Sample」使います。

• http://dddsample.sourceforge.net/

• DDD本にはそこまで詳しく触れられていなかった、DDDの実装方法が詰まっていて大変参考になります。

http://dddsample.sourceforge.net/

http://dddsample.sourceforge.net/


DDD実装のサンプル元

• 注意点としては、DDDSampleはDDD本を読んでいる事を前提されています。

• 内容は、DDD本に何度も出てくる、貨物輸送プログラムです。

• HPにクラス設計図等の説明が無いので、本を読まないと、「これは何クラス？」という状況に陥ります。


実装例一覧

本日提示させて頂く、実装例は、

• レイヤ化アーキテクチャ（少しだけ責務のレイヤも）

• 値オブジェクト

• エンティティ

• リポジトリ


レイヤ化アーキテクチャ



ソフトウェアの世界には、レイヤという便利な考え方があります。

有名なレイヤーといえば、MVC（Model View

Controller）ですよね。

一番不安定なView層から、Model層を直接参照・編集できないように切り離すことで、Model

層が安定します。（MVCが指すModelとDDDのモデルは微妙に異なります）



DDDのレイヤ化アーキテクチャも考え方は、同じです。

（ドメイン）モデルを様々な事象から可能な限り切り離すことで、モデルの安定化を目指します。



DDD本「第4章ドメインを隔離する」から抜粋

基本的に、上のレイヤは下位レイヤーを参照できるが、

逆に下から上へは参照できない構造。



ユーザインタフェース（またはプレゼンテーション層） • ユーザに情報を表示して、ユーザのコマンドを解釈する責務を負う。

• 外部アクタは人間のユーザではなく、別のコンピュータシステムのこともある。



アプリケーション層 • ソフトウェアが行うことになっている仕事を定義し、表現力豊かなドメインオブジェクトが問題を解決するように導く。

• このレイヤが責務を負う作業は、ビジネスにとって意味があるものか、あるいは他システムのアプリケーション層と相互作用するのに必要なものである。このレイヤは薄く保たれる。



ドメイン層（またはモデル層） • ビジネスの概念と、ビジネスが置かれた状況に関する情報、およびビジネスルールを表す責務を負う。

• ビジネスの状況を反映する状態はここで制御され使用されるが、それを格納するという技術的な詳細は、インフラストラクチャに委譲される。この層がビジネスソフトウェアの核心である。



インフラストラクチャ層 • 上位のレイヤを支える一般的な技術的機能を提供する。これには、アプリケーションのためのメッセージ送信、ドメインのための永続化、ユーザインタフェースのためのウィジェット描画などがある。

• インフラストラクチャ層は、ここで示す4 層間における相互作用のパターンも、アーキテクチャフレームワークを通じてサポートすることがある。

• 個人的感想としては、ここは「ごった煮」層。



それでは、早速実装をみてみましょう。



名前空間（フォルダ分け）などを使って、レイヤ分類を実装していました。

MVCもフォルダで分けたりするので、同じですね。

DDDSampleでは他にもフォ

ルダがありますが、ここでは解りやすくする為、省いています。



レイヤ化自体は、フォルダ（名前空間）分けという単純な方法でした。

しかし、MVC同様にどのオブジェクトはどのフォルダに格納すべきか、よく考える必要があります。


少しだけ、

責務のレイヤ


責務のレイヤ

• DDDSampleには直接記されていないのですが、DDDには、「責務のレイヤ」というレイヤ概念があります。

• モデル層内部をより細かく分類して、不安定箇所（仕様変更が多発する箇所）を切り離します。


責務のレイヤ

第16章大規模な構造「責務のレイヤ」より


責務のレイヤ

• 責務のレイヤは、開発に非常に有効な手段と思います。

• しかし、責務のレイヤを実装するには、顧客（ドメインエキスパート）の知識が必要となり、上流設計で行う作業やスキルが必要となります。

・業務知識の習得

・業務の見える化・・・色々

やはり、一筋縄ではいかなそうです。


値オブジェクト



• DDDでは、如何にモデルをシンプルに保つかが、大切な考えになります。

• オブジェクトに、責務以上の機能、余計なデータを持たせない事に、注意を払います。



• 値オブジェクトは、“属性情報”だけを持ちます。

• 属性情報とは、「色」や「大きさ」など、

対象の性質を表したものです。



そして、値オブジェクトは次のルールが適応されます。

• 同一性（アイデンティティ）を持たない。

• 不変（immutable）である。（属性に変更が必要になった場合、属性を変更するのではなく、

新しい属性を持った値オブジェクトを作成する）



DDDSampleのLeg（行程）をサンプルにして、実装をみてます。

Legは船の貨物の「積み込む地点」と、「荷下ろし地点」を保持します。

※ 単純化の為、DDDSampleから改変（省略）しています



//値オブジェクト用インターフェース

public interface IValueObject<T>

{

//属性が同じかチェック

bool SameValueAs(T other);

}

最初に、値オブジェクト用のインターフェースを用意。



//Leg（行程）の値オブジェクト実装

public class Leg : IValueObject<Leg>

{

public Location LoadLocation { get; private set; } //荷積み地点

private Location UnloadLocation { get; private set; } //荷下ろし地点

public Leg(Location loadLocation, Location unloadLocation)

{

this.LoadLocation = loadLocation;

this.UnloadLocation = unloadLocation;

}

public bool SameValueAs(Leg other)

{

if (this.LoadLocation != other.LoadLocation) return false;

if (this.UnloadLocation != other.UnloadLocation) return false;

return true;

}

} ※ 解りやすくする為に、DDDSampleから改変しています。



• Leg（行程）サンプルの特徴は、属性として、

・ LoadLocation（荷積み地点）

・ UnloadLocation（荷下ろし地点）

を持ち、コンストラクタ以外に、属性を変更する

手段を持ちません。

• このLeg(行程)だけみると、値オブジェクトと言っても、特別なことは無いように見えますね。



その２



• 次は、Leg（行程）をリストとして保持する、Itinerary

（運送スケジュール）オブジェクトを考えてみます。

• Itineraryは、Cargo（貨物）（後述するエンティティ）のLegをまとめたもので、Legリスト最初が出発点、最後が到着点（目的地）となります。



このItinerary（運送スケジュール）を値オブジェクトと考えた場合、不変性をどう考えればよいでしょうか？

リストとして保持しているLeg（行程）に、1つでも変更が生じた場合、Cargo（貨物）は、Itinerary

（運送スケジュール）を破棄して、都度、新しいインスタンスを用意しないといけないのでしょうか？



DDD本の第16章『大規模な構造』の「責務のレイヤ」に、次のように書かれています。

ソフトウェアにおけるこのレイヤは、計画作成と意思決定に用いるツールをユーザに提供し、潜在的には一部の意思決定を自動化できる

（運送スケジュールが変更になった時、自動的に貨物の経路を選択し直すなど）

つまり、意思決定支援レイヤの責務として、変更対応すればよいそうです。（うーん難しい！）



個人的解釈としては、

• 運送スケジュール変更というのは、Cargo（貨物）自体の責務ではない。

• スケジュール変更は、より上位の意思に寄るものである。（例：貨物運送担当者など）

• その為、 RoutingService（経路選択サービス）を用

意し、スケジュール変更に伴う実装的負担を引き受けることで、各オブジェクト構造をシンプルに保てる（余計な仕事をさせなくて済む）



• まずは、Itinerary（運送スケジュール）の実装をみてみましょう。



// Itinerary（運送スケジュール）オブジェクト

public class Itinerary : IValueObject<Itinerary>

{

private List<Leg> legs = null;

public Itinerary(List<Leg> legs)

{

this.legs = legs;

}

}

※ 解りやすくする為に、DDDSampleから改変しています。



Itinerary（運送スケジュール）は、単純にLeg(行程）をリストで保持しているだけですね。

次は、Cargo（貨物）とRoutingService（経路選択サービス）です。



// Cargo（貨物）（後ページのエンティティ時にも記載）

public class Cargo:IEntity

{

~省略~

//運送スケジュール

private Itinerary itinerary;

//運送スケジュール変更

public void AssignToRoute(Itinerary itinerary)

{

this.itinerary = itinerary;

}

}




// Itinerary（運送スケジュール）を新しく作るサービスを用意

public class RoutingService

{

public List<Itinerary> fetchRoutesForSpecification(Cargo cargo)

{

//新しいltinerary（運送スケジュール）割り当て

cargo.assignToRoute(toItinerary());

}

//条件に従い、新しい運送スケジュール作成

private Itinerary toItinerary() {

~省略~

return new Itinerary(legs);

}

}




DDDSampleにおける実際のRoutingService

（経路選択サービス）はもっと複雑です。

ただ、DDD的意図を読み取ると、経路変更の仕事を、経路情報を持つCargo（貨物）に行わせるのではなく、Serviceとして外部に出したことにより、Carg（貨物）がシンプルに保たれている事に、意義があるのと考えています。


エンティティ


エンティティ

• エンティティは値オブジェクトと異なり、同一性（アイデンティティ）を持ちます。

• 同一性は、モデルのライフサイクル期間中保たれます。

• 同一性は、エンティティをDB格納して、取り出した後でも、保たれます。

エンティティ

モデルのライフライン

DB エンティティ

同じアイデンティティ


エンティティ

• cargo（貨物）をサンプルに、エンティティの実装を見てみます。

• cargo（貨物）は、TrackingId（追跡ID）をアイデンティティとして、同一性を持ちます。

• TrackingId（追跡ID）は、作成時に割り当てられた後、変更されることはありません。


エンティティ

// エンティティ用インターフェース

interface IEntity<T>

{

//同一エンティティかチェック

bool sameIdentityAs(T other);

}

• まずはエンティティ用のインターフェース


エンティティ

//cargo（貨物）

public class Cargo:IEntity<Cargo>

{

private readonly TrackingId trackingId;

public Cargo(TrackingId trackingId) {

this.trackingId = trackingId;

}

public bool SameIdentityAs(Cargo other)

{

return other != null && trackingId.sameValueAs(other.trackingId);

}



エンティティ

• アイデンティティであるtrackingId（追跡ID)をreadonlyにすることで、設定後の不意な変更を防止しています。

• それ以外は特段特徴のない、普通のクラスですね。


エンティティ

• 次に、そのアイデンティティとして使用されている TrackingId（追跡ID）の実装を見てみます。


エンティティ

// TrackingId（追跡ID）

public sealed class TrackingId : IValueObject<TrackingId>

{

private readonly String id;

public TrackingId(String id) {

this.id = id;

}

public override bool Equals(object o) {

if (this == o) return true;

if (o == null) return false;

TrackingId other = (TrackingId)o;

return SameValueAs(other);

}

public bool SameValueAs(TrackingId other) {

return other != null && this.id.Equals(other.id);

}



エンティティ

• 驚いた事に、 TrackingId（追跡ID）は値オブジェクトです。

• Cargo（貨物）は、エンティティですが、そのアイデンティティとして、値オブジェクトであるTrackingId（追跡ID）を使用しています。


エンティティ

これらの事から、何が値オブジェクトで、エンティティなのか、深く考える必要があることが伺えます。（エンティティのアイデンティティも、普通ならエンティティになると普通思うと思います）

個人的には、容易にオブジェクトをエンティティとしないという、強い意志を感じました。


Factories と Repositories



• エンティティの実装例で見た通り、同一性の確保は、プログラムの実装に依存します。（例では、追跡IDのユニーク性確保など）

• このように、新しくオブジェクトをnew（インスタンス化）したいときに、特定条件（今回は追跡ID採番）を実行したい事は多々あります。



• そこで、オブジェクトの生成、並びにDBへの格納・取り出しなど、オブジェクト化するのに必要な処理をまとめたのが、「Factories（ファクトリ）」と「Repositories（リポジトリ）」です。



• 「Factories」がオブジェクト生成時に使用。

• 「Repositories」は、DB格納や取り出しなど、オブジェクトを使いまわす時に使用します。



• cargo（貨物）を格納するCargoRepositoryの実装例は次のようになります。



//貨物リポジトリ

interface ICargoRepository

{

//指定、追跡IDに該当するcargo取得

Cargo find(TrackingId trackingId);

//全cargoを取得

List<Cargo> findAll();

//DBに格納します

void store(Cargo cargo);

//DBなどのシーケンスを使い、ユニークなIDを発番させます。

TrackingId nextTrackingId();

}



• ICargoRepositoryインターフェースを実装することで、O/Rマッパで実装するとDBに結びつけたり、ファイル操作で実装すると、Textファイルとして保存させたり、することができます。

• 次ページはDBで実装した時の例です。



//貨物リポジトリ（DB）

public class CargoRepositoryDb

{

private DAO dao=null;

//指定、追跡IDに該当するcargo取得

public Cargo find(TrackingId tid) {

dao.createQuery("from Cargo where trackingId = :tid"); //SQL

dao.setParameter("tid", tid);

return dao.result();

}

//全cargoを取得

public List<Cargo> findAll() {

dao.createQuery("from Cargo "); //SQL

return dao.result();

}

(続く) ※ 解りやすくする為に、DDDSampleから改変しています。



(続き)

// DBに格納します

public void store(Cargo cargo){

dao.saveOrUpdate(cargo);

dao.createSQLQuery("delete from Leg where cargoId =null").executeUpdate();

}

// ユニークなIDを発番

public TrackingId nextTrackingId() {

var randomId= dao.GetRoundomUID();

return new TrackingId(randomId);

}

}




Factoriesの実装例は載せておりませんが、Repositoriesとほぼ同じような実装内容になります。

そうなってくると、FactoriesとRepositoriesをまとめても良さそうに思いますよね？



しかし、DDD本では、次の理由でFactoriesとRepositoriesの役割を分離させてます。

• Factoriesは、新しいオブジェクトを生成する責務。

• Repositoriesは、既存オブジェクトを再構成する責務。

• 分離させることで、FactoriesをDB（永続）化する処理から分離できる。


まとめ


まとめ

簡単な実装例だけでしたが、

• レイヤ化アーキテクチャ

• 値オブジェクト

• エンティティ

• Repositories

DDDの中核をなす、実装例を見て頂きました。


まとめ

他にもDDDSampleでは、

• 集約（Aggregate）

• ドメインイベント

• Service

• 仕様（SPECIFICATION）

などの実装例が紹介をされています。

（しかし、これらはDDDを知らないと、判りづらいかもしれません）


書籍紹介

次に、DDD実装で参考になる書籍を簡単に紹介させていただきたいと思います。


書籍紹介

ドメイン駆動 ■amazon

http://www.amazon.co.jp/dp/4798116173

■書籍紹介

C#を使った、ドメイン駆動設計をパターンを使って実装していく実践本です。

まさに、C#er向けの一冊。

C#2.0と若干古いのですが、サンプルソースは参考になります。

SQLServerと如何に連携させるか、

テスト駆動開発でいかに進めるかなど、

てんこ盛りな内容です。（少々詰め込み過ぎ？）




書籍紹介

Implementing Domain-Driven Design ■amazon

http://amzn.com/0321834577

■書籍紹介

英語本ですが、IDDDというキーワードでよく見かける、DDD実践本です。

DDD本の後に出版された、如何にDDDを実践していくかを主眼に書かれている本で、DDD本には収録さ

れていなかったドメインイベントも記載されているようです。

DDD本に劣らない分厚さを誇ります（汗。

私は当然、英語苦手なので未読です（汗汗

IDDDのワークショップを世界的に行うコミュニティがあるようです。（http://idddworkshop.com/）




まとめ

最初にも書かさせて頂きましたが、DDDにおける実装が占める役割は、ほんの一部です。

実装に至るまでの過程がもの凄く重要だと思います。

また、実装例として挙げたものより、状況によって、より適切な実装方法は、数多くあると思います。


まとめ

今回は、実装という方面からDDDを眺めてみましたが、DDDを知らなかった方に、少しでも興味を持って頂けたのなら幸です。

DDDの実装については、私も勉強中です。

もし気になる点などありましたら、是非お声かけ下さい。<(_ _)>ﾍﾟｺﾘ


まとめ

以上、ご清聴ありがとうございました。

c＃実装から見るddd(ドメイン駆動設計)

Technology