2015.04.16（木） DDD.rb用発表資料です。 開発プロジェクトにどれぐらい、DDD導入が適応可能か判定するチェックシートです。 というのは建前で、『プロジェクトにDDDは間違いなく必要ですよ。役立ちますよ。是非導入してくださいね♪』が言いたかっただけです。

1. DDD導入判定
チェックシート！
1
2015.04.16 DDD.rb LT用

2. 自己紹介
2
●かわべ たくや
●Twitter : @kawakawa
●大阪にてDDD奮闘中

3. DDD導入判定チェックシートとは？
実践ドメイン駆動設計に掲載されて
いるDDDチェックシート（p11）を元に、
プロジェクトにDDDを導入する価値が
あるか、判定するシートを作ってみま
した♪
10問の合計ポイントで判定します。
それでは、早速スタート！
3

4. チェック#1
納品が３日後に迫っている。
または、デスマーチ中だ！
4
・はい（+0 ポイント）
・いいえ（+1 ポイント）

5. チェック#2
DBは使っているがテーブル数は少なく、
プログラムもCRUD（作成、読込、更新、削除）
以外の処理は行わない。
5
・はい（+0 ポイント）
・いいえ（+1 ポイント）

6. チェック#3
ユーザーストーリ数が３０程度以下だ。
6
・はい（+0 ポイント）
・いいえ（+1 ポイント）

7. チェック#4
少なくとも半年以上は運用する。
7
・はい（+1 ポイント）
・いいえ（+0 ポイント）

8. チェック#5
レガシーシステムに、新機能追加を行う。
8
・はい（+1 ポイント）
・いいえ（+0 ポイント）

9. チェック#6
DBの変更、タッチデバイス対応など、何らかの
アーキテクチャ変更が予定されている。
9
・はい（+1 ポイント）
・いいえ（+0 ポイント）

10. チェック#7
今まで経験したことのない分野の開発を行う。
10
・はい（+1 ポイント）
・いいえ（+0 ポイント）

11. チェック#8
顧客が良く判らない専門用語を話している。
11
・はい（+1 ポイント）
・いいえ（+0 ポイント）

12. チェック#9
逆に自分が、顧客が判らないIT用語（DB、フレー
ムワーク、並列化などなど多数）を使って、会話して
しまっている。
12
・はい（+1 ポイント）
・いいえ（+0 ポイント）

13. チェック#10
プロジェクトに顧客が複数おり、それぞれ部署が
異なる
13
・はい（+1 ポイント）
・いいえ（+0 ポイント）

14. はい、チェック終了です。
何ポイントになったでしょうか。
次ページから、
DDD導入判定の結果発表です。
14

15. 合計：０ポイント
DDD導入に時間を割いたとしても、
得られる効果は少なそうです。
しかし、DDDが導入出来ないという意味ではあり
ません。
将来システムが複雑化する可能性があるのな
ら、DDD導入の価値は十分にあります。
15

16. 合計：１～４ポイント
DDD導入する価値はあります。
まずは、『ユビキタス言語』 『ファクトリ』 『リポジト
リ』など、技術面からDDDを行う軽量DDDを採用
してみては如何でしょうか。
しかし、軽量DDDではドメインモデル貧血症に陥
りやすい事に注意してください。
16

17. 合計：５～８ポイント
システムは十分に複雑そうです。
DDD導入の価値は大きいでしょう。
複雑なドメインに立ち向かうには、戦略的設計が
必要です。
顧客（ドメインエキスパート）と協力してDDDを導
入してみてください。
17

18. 合計：９～10ポイント
かなり複雑なシステムのようです。
DDDが無いとシステムは巨大な泥団子になって
しまい、少しの機能追加・変更でも、多大な苦労
や時間を強いられる事になります。
まずはDDDを導入し、『コンテキストマップ』を作
成した後、『コアドメイン』を見つけ出すことに専念
してください。
18

19. 皆さんの結果は如何だったでしょうか。
私は、DDDはシステムが変化し続けるための手
法だと思っております。
システムが単純な時からDDDを導入しておけ
ば、将来複雑化していったとしても、十分対応出
来るようになると思います。
どのようなプロジェクトであれ、まずはDDD導入を
前提で始められる事をお勧めします。
19

20. 次ページからは、
設問のちょっとした解説です。
20

21. チェック#1
納品が３日後に迫っている。
または、デスマーチ中だ！
21
この場合、DDDではなく他の問題である気がしま
す（汗
まずは動くプログラムを目指しましょうか。
「DDDで開発しています！
でもプログラムはまだ動きません（ｷﾘｯ」
これでは意味がありませんものね。

22. チェック#2
DBは使っているがテーブル数は少なく、
プログラムもCRUD（作成、読込、更新、削除）
以外の処理は行わない。
22
CRUD以外行わない場合、DBを使った巨大な
getter/setter と考えられます。振る舞いが無い
ので、DDD導入価値は低いと思います。
しかし、テーブル数が増えてくると、振る舞いが
生じる可能性が高いのです。

23. チェック#3
23
ユーザーストーリ数が３０程度以下だ。
ユーザストーリが少ないうちは『トランザクション
スクリプト』でも対応は可能だと思います。
しかし、見積もりが甘いことにかけては定評があ
る私たち開発者としては、後でストーリ数が増え
る前に、DDD導入を検討しておきましょう。

24. チェック#4
24
少なくとも半年以上は運用する。
半年以上稼働するのなら、仕様変更は必ず発生
します。
コーラを飲んだらゲップが出るぐらい確実です。
DDDを導入しておけば、対応できる可能性を高
める事ができます。

25. チェック#5
レガシーシステムに、新機能追加を行う。
25
レガシーシステムと新追加機能の連携が困難な
場合、間に『腐敗防止層』を設けて、ドメインを分
けてしまう方法があります。

26. チェック#6
26
DBの変更、タッチデバイス対応など、何らかのアーキテクチャ
変更が予定されている。
アーキテクチャ変更で実装方法が変更される可
能性がある場合、『責務のレイヤー』を用いてドメ
インモデルと実装を分離させておく方法がありま
す。

27. チェック#7
27
今まで経験したことのない分野の開発を行う。
経験のない分野での開発は、ドメインがどうなっ
ているのか、作成したモデルが正しいのか判りま
せん。
『戦略的設計』を行うことで、ドメインの複雑さに
立ち向かうことができます。

28. チェック#8
28
顧客が良く判らない専門用語を話している。
顧客（ドメインエクスパート）が言っている単語が
判らない場合、顧客が当然と思っている挙動・振
る舞いを、見逃す危険性があります。
顧客と一緒に『ユビキタス言語』を作成して、意思
疎通が図れるようにしましょう。

29. チェック#9
逆に自分が、顧客が判らないIT用語（DB、フレームワーク、並
列化などなど多数）を使って、会話してしまっている。
29
顧客（ドメインエクスパート）が知らない・良く判ら
ない単語で話してしまうものNGです。
やはり『ユビキタス言語』を作成して、意思疎通が
図れるように心掛けましょう。

30. チェック#10
プロジェクトに顧客が複数おり、それぞれ部署が異なる
30
同じ会社でも、部署が変われば別会社。
同じ単語を話していても、違う意味を持っている
可能性があります。
『コンテキストマップ』を用いて、ドメイン境界線を
把握しておきましょう。