• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
ドメイン駆動設計入門
 

ドメイン駆動設計入門

on

  • 18,914 views

 

Statistics

Views

Total Views
18,914
Views on SlideShare
18,806
Embed Views
108

Actions

Likes
83
Downloads
94
Comments
0

7 Embeds 108

https://twitter.com 59
http://blog.livedoor.jp 24
http://s.deeeki.com 14
http://b.hatena.ne.jp 4
http://tweetedtimes.com 4
https://www.chatwork.com 2
http://twicli.neocat.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    ドメイン駆動設計入門 ドメイン駆動設計入門 Presentation Transcript

    • ドメイン駆動設計への手引き 関西Javaエンジニアの会'13 7月度 2013/07/31 @chipstar_light
    • エリック・エヴァンスのドメイン駆動設計 エリック・エヴァンス (著), 今関 剛 (監修), 和智 右桂 (翻訳), 牧野 祐子 (翻訳) 出版社: 翔泳社 発売日: 2011/4/9 原書発売日: 2003/8/22 http://www.amazon.co.jp/エリック・エヴァンスのドメイン駆動設計 -IT-Architects’Archive-ソフトウェア開発 の実践-エリック・エヴァンス /dp/4798121967/
    • 今日のお話 ● DDD本の概略 ○ ドメイン駆動設計の基本的な考え方 ○ ドメインモデルの構成要素 ○ DDD本に沿って解説 ● DDDの目次 第1部 ドメインモデルを機能させる 第2部 モデル駆動設計の構成要素 第3部 より深い洞察へ向かうリファクタリング 第4部 戦略的設計 今日は ここ!
    • ドメインモデルとは? ● モデル ○ 現実にある”もの”や”こと”を、関心毎に絞ってシンプルに図示したもの ○ 選び抜かれてシンプルにされ、意図的に組み立てられた知識の表現形式 ○ 複数の人間の間で知識を共有するツール ● ドメインモデル ○ システム化の対象となるドメイン(業務)の知識を抽象化して図示したもの ○ ドメイン駆動設計を実践する上で、開発者とドメインエキスパートをつなぐ共通 の知識表現 ● ドメインエキスパート ○ プロジェクトに参加する業務の全体像を詳しく理解している人 ○ DDDにおけるドメインモデルはドメインエキスパートと共同で作り上げるもの
    • 例:貨物輸送システム ● ● ● 顧客が依頼した貨物の状況を追跡するシステム あらかじめ貨物を予約する 貨物が荷役の過程で所定の場所に到着した際に、自動的に請求書を顧客に送 付する
    • ユビキタス言語 ● ドメインモデルを用いたチーム内での共通の言語 複雑な開発にはコミュニケーションが重要 ○ ドメインエキスパートと開発者はそれぞれ独自の専門用語で知識を表現し ようとしてしまう ○ ドメインモデルをコミュニケーションにおける共通言語としよう ○ ● ドメインモデルをユビキタスな言語にする ○ ユビキタス言語がプロジェクトの全てのメンバーに行きわたり、設計から開 発、モデルからコードまで全ての成果物に反映されていること ○ ドメインエキスパートはユビキタス言語を通してそのドメインの理解を適切 に伝えられているかを見極める ○ 開発者はユビキタス言語により設計の曖昧さが排除されているかを見極め る
    • モデル駆動設計 ● モデルをそのまま実装に落とす手法 ○ ● モデルを基に、コードでそのモデルの概念やモデルそのものを表現する モデルとコードを緊密に関係づける ○ ドメインモデルをユビキタス言語にするためには、その内容をコードにも落と す必要がある ○ ドメインモデルとコードは常に整合性を保っていなければならず、それを実現 する手段としてモデル駆動設計を用いる ● 分析モデルと設計モデルという二分法を捨て去る ○ ビジネスドメインの理解のために分析モデルを作る事があるが、この用途の モデルでは実装の問題が留意されない ○ モデル駆動設計では、分析・設計の両側面から使える単一モデルを探し出す ようモデルを蒸留する
    • ドメイン駆動設計とは? ● ドメインモデルを中心とした設計・開発手法 ● 開発者がドメインエキスパートと共同でドメイン知識を抽象 化したドメインモデルを作り上げる ● ドメインモデルをユビキタス言語としてドメインの知識を共有 化する ● モデル駆動設計によりユビキタス言語化されたドメインモデ ルをそのまま実装に落とし込む ドメイン(業務)の変更につよいアジリティ の高いシステムを作る
    • レイヤ化アーキテクチャ ● ドメインを隔離する ○ ○ ドメインオブジェクトをシステムの他の機能から切り離す ドメインオブジェクトが、UIやDBといったソフトウェアの概念から影響を受け にくくする
    • モデルの構成要素 ● モデルを表現する要素 ○ ドメインオブジェクトは基本この3つの何れかに分類される Entities Value Objects Services ● モデルのライフサイクル ○ ドメインオブジェクトのライフサイクルを表現・管理するためのパター ン Aggregates Factories Repositories
    • Entities ● 抽象的な連続性と同一性 ○ 固有のIDを持ち、実装をまたいだとしても追跡されるような連続性を持つオ ブジェクト ○ 分散環境下でも、永続化前後でも追跡できないといけない ● 属性(状態)に左右されない同一性 ○ ○ 連続性を保証するIDは、オブジェクトの属性値に左右されない ○ 同一性の判断とライフサイクルは、モデル毎に個別に設計する 属性値が全て同じでもIDが異なれば別もの 属性値が異なっていてもIDが同じであれば同じもの ● 具体例 ○ 顧客、口座、注文、在庫、etc...
    • Value Objects ● 連続性と同一性が不要なオブジェクト ○ ○ ○ 属性がどんな値であるかに焦点が置かれるもの 一過性のことも多く、操作のために生成されては破棄される 状態を変更できないもの(immutable)として扱う ● 他の何かの状態を記述する属性となる ○ 「何」であるかだけが問題となり、「誰」であるか、あるいは「どれ」であるか は問われないような設計の要素 ○ エンティティの属性としても使用される ● 具体例 ○ 色、量、地域、経路、etc...
    • Services ● EntityやValueObjectには不自然な操作 ○ 1つの機能や処理が単体で存在していて、もの(オブジェクト)として扱うの が不自然なものもある ○ 操作であり状態を持たない ● EntityとValueObjectのコントローラ ○ EntityとValueObjectの集合体で構築され、ドメインの能力をまとめ上げる スクリプトとしてふるまうものが多い ○ EntityとValueObjectは、ドメイン層の持つ能力への便利なアクセスを提供 するには、粒度が細かすぎる事が多いための対処 ● サービスはドメイン層だけのものではない ○ アプリケーション層やインフラストラクチャ層にもある ○ ビジネスに関係する処理を持つサービスだけをドメイン層に配置する
    • 適用例:EntitisとValueObjectsを区別する
    • Aggregates(集約) ● オブジェクトのまとまりを作る ○ 関連するオブジェクトの集まりであり、データを変更するための単位 ○ モデル内にある参照をカプセル化するための抽象化 ● 各Aggregateにルートと境界を設ける ○ ルートはAggregateに含まれている特定の1エンティティ ○ 外部オブジェクトから参照できるのはルートのみ ■ 境界内のオブジェクトに対する処理はすべてルートを経由する ■ データベースに問い合わせて直接取得できるのはルートだけ ○ Aggregateに明確な所有権と境界を定義し、関連を最小限に抑える ● 境界内のオブジェクトに対する一貫性を保証する ○ ルートが境界内のオブジェクトの不変条件をチェックする ● 具体例 ○ 「注文」と「注文明細」、「車」と「タイヤ」や「エンジン」などの各種パーツ
    • 適用例:Aggregatesの境界を定義する
    • Factories ● オブジェクトやAggregateの生成をカプセル化する ○ ○ ○ 生成されるオブジェクトとクライアントを疎結合に保つ 複雑になりがちな生成処理を隠蔽する 生成するオブジェクトの不変条件を強制する ● オブジェクトを再構築する ○ ○ ライフサイクル中に永続化されたオブジェクトを復元する処理 生成時とは異なる振る舞いになる ■ IDの採番や不変条件のチェック後の振る舞いなど ● ファクトリはドメインモデルではない ○ オブジェクトの生成がドメイン上の重要な意味を持つ事がないため ○ 但し実装には必要なドメインの構成要素
    • Repositories ● 永続化されたオブジェクトへのアクセス手段を提供する ○ ○ ○ ● オブジェクトのライフサイクルの中期を管理する ○ ○ ○ ● ファクトリは新しいオブジェクトを生成する リポジトリは古いオブジェクトを見つけ出す リポジトリ内部で発生する再構築処理はファクトリへ委譲する 集約ルートに対して一つのリポジトリを用意する ○ ● DB等の永続化インフラストラクチャをカプセル化する 複雑になりがちなデータストアに対するCRUD処理を隠蔽する オブジェクトのコレクションがメモリ上にあると錯覚させる 集約ルート以外のオブジェクトにグローバルなアクセスは提供しない ファクトリ同様ドメインモデルではない
    • 適用例:Repositoresを選択する
    • まとめ ドメイン駆動設計を読んでみようと思った方は...
    • 京都DDD読書会告知 http://connpass.com/series/246/ ● 京都で行うDDDの読書会 ● 3週間に一度水曜日に開催 ● ○ 次回はモデリングのワークショップ こんな人、大歓迎! ○ DDDを読もうと思ってたけど一人で読むの大変だった人 ○ これからDDDをやってみたい人 ○ これを機にDDDを読もうという人
    • 参考資料 ● DDD難民に捧げる Domain-Driven Designのエッセンス ○ オブジェクトの広場 ○ http://www.ogis-ri.co. jp/otc/hiroba/technical/DDDEssence/chap1.html ● ドメイン駆動設計・アプリケーション構築編 ○ ストラテジック チョイス ○ http://d.hatena.ne.jp/asakichy/20110509/1304899807