Address
:
[go:
up one dir
,
main page
]
Include Form
Remove Scripts
Accept Cookies
Show Images
Show Referer
Rotate13
Base64
Strip Meta
Strip Title
Session Cookies
More Web Proxy on the site http://driver.im/
Submit Search
ドメイン駆動設計という仕事の流儀
•
110 likes
•
16,554 views
増田 亨
Follow
Devlove2012 カンファレンス 発表資料。 ドメイン駆動設計。アプリケーションアーキテクチャ、開発プロセス、設計スタイル。腕を磨く。
Read less
Read more
1 of 53
Download now
Downloaded 283 times
More Related Content
ドメイン駆動設計という仕事の流儀
1.
DevLOVE 2012 ドメイン駆動設計という
仕事の流儀 2012年12月16日 有限会社 システム設計 増田亨
2.
Domain-Driven Design (DDD)
ドメイン駆動設計
3.
ドメイン駆動設計の 腕を磨くと
4.
仕事が楽しくなる 喜んでもらえる
自分の成長の手ごたえ やっていて面白い
5.
ドメイン駆動設計
興味を持つ 利用者の やりたい事 いつも 話題にする モデルに要約する コードで実現する
6.
ドメイン駆動設計的な ・アーキテクチャ ・開発プロセス ・設計スタイル
7.
Domain-Drivenな アプリケーション
アーキテクチャ
8.
ドメインモデル指向の設計パターン 業務活動のトリガー
業務手順の要約 業務の知識 ドメイン 起動 ドメイン 委譲 ドメイン イベント サービス モデル 入会申込 受付() -申込番号 { 会員とは? -氏名 検証(); 入会とは? -連絡先 記録(); 申込とは? -申込日時 通知(); 受付とは? } "something interesting "represents a Use Case scenario" “an Object Model which affects the domain" "delegate to other objects " of the Domain” [EAA-dev, Fowler] [GRASP : Controller] [PoEAA]
9.
ドメイン層の基本部品 業務イベント 入会申込
会員リポジトリ 会員登録サービス << interface >> イベント << controller >> リスナ 登録する(会員) : void 登録する(会員) : void 存在を確認(会員) : Boolean DIP DBアクセス 会員 会員トランスファー << interface>> <<domain object>> 連絡手段 Thank Youメール送る(会員) : void 関係部門に通知する(会員) :void 通知先() : メールアドレス 業務の用語、業務のルール メール送信 DIP メッセージング
10.
アンチパターン 大きなサービスクラス
get 5以上のimport文 get get データの入れ物だけの 5以上のインスタンス変数 set ドメインオブジェクト 10行以上の長いメソッド set set 50行を超えるクラス メソッドは getter/setter だけ ドメインサービスクラスが 業務の流れ・構造・ルールの いろいろ知っていて、 理解が不十分なまま作った、 とりあえずの置き場所に、 なんでもやりたがる なんでも突っ込んでいく (偶発的凝集)。
11.
ドメインモデル指向の フレームワーク
Spring MVC SQLマッピング myBatis Bean バリデータ ドメイン メッセージング Spring JMS Hibernate モデル テンプレート OXマッピング エンジン JAXB Velocity 業務の知識
12.
ドメインイベント駆動の実行環境
ドメイン ドメイン ドメイン イベント イベント イベント HTTP リクエスト メッセージング (Web アプリ, Web API) (システム間連携) 電子メール受信 アプケーション メッセージング メールサーバー サーバー サーバー James Tomcat Active MQ サービス Mailet Servlet コンテナ コンテナ コンテナ Mule ESB ドメインサービス ドメインモデル
13.
Domain-Drivenな 開発プロセス
14.
ドメイン駆動の開発プロセス
ドメインの把握 ユースケース 画面・帳表 コンテキスト 業務フロー ロバストネス分析 イベント 状態遷移 必要ならシーケンス図 初期のラフモデル モデルの改良 属性の追加 操作追加 基盤クラス追加 モデルの洗練 Java ソースコー ド DDL/SQL 手がかかり 要約、骨格 構造化用語集 ソースコー ド ドメインモデルの設計と実装 データモデル
15.
ドメインを把握する リレーションシップ駆動 要件定義(RDRA)
ICONIX 初期のラフモデルを 2時間以内で描く ・コンテキストモデル ・業務フローモデル ・ドメインオブジェクトの発見 ・イベント/状態モデル ・ドメインモデルの育て方 ・ロバストネス分析 モデル間を関連づけ ユースケースと 整合性と網羅性を確保 実装のギャップを埋める ビジネスルールの発見と定義 業務フロー図から ドメインモデルから イベント/状態モデルから それぞれのモデルから ビジネスルールを抽出する ヒントとテクニック
16.
インクリメンタルに • Evolving ドメインモデルを育て続ける
– 小さく生む – フィードバックを反映しながら育てる • Pervading ドメインモデルを行渡らせ続ける – 多くの関係者 – あらゆるタスク – ドメイン以外のレイヤ • Binding ドメインモデルを 結びつけ続ける – 利用者の関心事とモデル – 実装コードとモデル
17.
イテレーティブで発見的に より良い部品を探し続ける モデリング プログラミング
リファクタリング 三位一体 繰り返し
18.
ドメインモデルの 設計スタイル
19.
設計原則 二本柱 ギュッと
サラッと 集めて つなぐ High Cohesion Low Coupling ドメインオブジェクトに適用する
20.
業務の知識を ギュッと集める ・パッケージ ・クラス ・メソッド
High Cohesion
21.
業務の概念ごとに 独立させて サラッとつなぐ ・パッケージ ・クラス
Low Coupling
22.
ドメインモデルの設計
腕を磨く 小さな部品 How より What 設計の本を読む 原則・パターンとの付き合い方
23.
ドメイン駆動設計への道
実装のテクニック ドメインの理解 ・メソッドの構成 設計のスタイル ・オブジェクト間の特性の移動 言葉の力 小さく作る練習 ・データの再編成 ・条件記述の単純化 モデル駆動 オブジェクト指向 エクササイズ ・役割ステレオタイプ 9つの簡単なルール ・メソッド呼び出しの単純化 ・小数の隣人と協力 RDD 責任の割当の原則 GRASP For Thoughtful Developer 実装の原則 凝集と結合の原則 Leading Designer SOLID ・クラス RCC ・振る舞いとメソッド ASS ・状態とコレクション
24.
腕を磨く 小さな部品
25.
部品(業務の基本用語)の粒度 日付 (時分秒を持たない)
金額 管理番号,登録番号 時分(秒を持たない) 単価 取引先コード 翌営業日, 休前日 数量,数量単位,換算 取引区分 月末,月初, 四半期, 半期, 年度 消費税,税率,端数処理 契約番号 期間 合計,小計,総合計 商品番号 有効期限 数量割引 型式コード 予定日 キャンペーン価格 製造番号 期限切れ一週間前のアラート 季節料金 シリアルナンバー 前日のリマインダ キャンセルポリシー … … … Date, String, BigDecimal, Long, … 小さな部品に プリミティブな型をラッピングした 業務で必要なデータとロジック(知識、ルール)を 凝集(カプセル化)する
26.
ドメインオブジェクト 第5章 オブジェクト指向 エクササイズ
小さく作る クラス 50行まで メソッド 3行まで パッケージ 10ファイルまで
27.
3行メソッド nextStage() {
ready(); set(); go(); } こういうのが良い感じ
28.
必然的に
オブジェクト指向(小さく) になる 9つの簡単なルール 「Thought Works アンソロジー」 第5章 オブジェクト指向エクササイズ 原文 http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf
29.
小さく作る練習課題 1.ひとつのメソッドのインデントは1段階まで 2.else 句 を使わない 3.すべてのプリミティブ、文字型をラッピング 4.ファーストクラスコレクションを使う 5.1行につき、ドットはひとつ 6.名前は省略しない 7.クラス50行、パッケージ10ファイルまで 8.インスタンス変数は2つまで 9.getter/setter
を使わない
30.
小さく作る練習ガイド
パターン集 第5章 オブジェクト指向エクササイズ パターン集 9つのルール slideshare: オブジェクト指向できていますか? http://www.slideshare.net/MoriharuOhzu/ss-14083300 オブジェクト指向エクササイズのススメ http://www.slideshare.net/yojik/ss-1033616 オブジェクト指向の設計と実装 学び方のコツ http://www.slideshare.net/masuda220/ss-14263541 原文 http://www.bennadel.com/resources/uploads/2012/ObjectCalisthenics.pdf
31.
小さな部品
実践の小技 汎用部品 より 目的特化部品 if 文を減らす・隠す for 文を減らす・隠す setter を使わない getter を使わない
32.
汎用部品
より 目的特化部品 String AreaCode Long EntryNumber BigDecimal ラッピング Amount Date ExpireDate List<Appoint> Appointments なんでも屋 目的特化
33.
if
文を減らす・隠す Boolean より Enum Strategy/State パターン Missing Object パターン (null object パターン) Map パターンマッチング …
34.
for
文を減らす・隠す ・ファーストクラスコレクションに隠す ・Collection フレームワーク API の復習 たとえば、TreeMap, TreeSet 必要なら ・Comparable の実装 ・Comparator の実装 ・equals()/hashCode() の override
35.
setter
を使わない 完全コンストラクタ ・Value Object パターン ・生成時に必要な値をすべて渡す 状態を変えたい時 ・別のオブジェクトを作る ・ライフサイクルの短いクラスの導入 (状態を固定できるまで細分化)
36.
getter
を使わない @Deprecated フレームワークは使っていいよ アプリケーションでは使っちゃだめよ get して何したいのか? もう一度考え直す ロジックを移動する (データにロジックを寄せる) フィールドを移動する (ロジックにデータを寄せる)
37.
腕を磨く How
より What
38.
How
より What 業務要件:期限切れの前日にアラートメールを送る expireDate.add(-1); expireDate.previousDay(); expireDate.dayOfFinalAlert ();
39.
How
より What 料金の用語( What ) をクラスで表現 計算方法( How ) を記述 課金ポリシー 適用する() 料金 シーズン料金 計算する() <<interface>> レート() ルール変更・追加のたびに クラスが肥大化し 夏料金 冬料金 if 文が増殖する予感 レート() レート() ルール変更・追加は、 一部の部品の追加、差し替えで すみそう。
40.
腕を磨く 本を読む 設計の
41.
いろいろな設計の考え方に触れる
広がりと掘り下げのT字 多くの本に目を向け、視野を広げる。 (浅くて良い。建築や機械、他分野まで広げる。) これぞと思う本は、徹底的に読み込んで深く理解する。 両方やることがたいせつ。 © 慶応大学 SFC 井庭研 学習パターン
42.
技術書を読み込む
鳥の眼と虫の眼 俯瞰して全体を見る。 詳細に部分を見る。 2つの視点を行き来する。 小説じゃないだから、 最初から順番に読んで面白いわけがない。 知らないことが書いてあるんだから、 一読で、わかるわけがない。 鳥の眼と虫の眼で何度も読み直す © 慶応大学 SFC 井庭研 学習パターン
43.
設計技術を自分のものにする
プロトタイピング 実際に作って覚える。 設計用語は、コードを書いて、動かして 「はじめて」わかることばかり。 設計用語をひとつ覚えるたびに、 昨日のコードと今日のコードの違いが 自分でわかるようになる。 それが「設計の考え方」「見方」の変化。 © 慶応大学 SFC 井庭研 学習パターン
44.
腕を磨く 設計原則 デザインパターン
付き合い方
45.
DDDのパターンの源流 RDD:
Responsibility Driven Design 18の基本用語(第1章) GRASP: General Responsibility Assignment 9つの責任割り当て汎用パターン SOLID: 5つのクラス設計の原則 RCC:3つのパッケージの凝集度の原則 ASS:3つのパッケージの結合度の原則
46.
設計原則・デザインパターン
との付き合い方 北極星、 in the context、 as a whole
47.
設計原則を北極星として使う 北極星に行きたいわけではない。 現在の進行方向の確認に使うだけ。 南に進むことが、 時には役に立つこともある。
48.
in the context 設計原則やデザインパターンは、 特定の文脈(背景、事情、前後関係)の 中での使い方を探す。 文脈が違えば 原則・パターンの使いどころも変わる。 その文脈でのベストプラクティスを探す。
49.
as a whole ドメインモデルが、 全体として、
役に立つか? 心地よいか? 設計原則やパターンへの執着が、 ドメインモデルを 台無しにすることもある。
50.
まとめ
51.
ドメイン駆動設計
興味を持つ 利用者の やりたい事 いつも 話題にする モデルに要約する コードで実現する
52.
腕を磨く 小さな部品
How より What 設計の本を読む 設計原則とうまく付き合う
53.
仕事を楽しく 喜んでもらう 自分が成長する
面白いことをやる
Download