ドメイン駆動設計（DDD）導入判定チェックシート

Transcript

• 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 同じ会社でも、部署が変われば別会社。 同じ単語を話していても、違う意味を持っている 可能性があります。 『コンテキストマップ』を用いて、ドメイン境界線を 把握しておきましょう。