Designer meets Domain-Driven-Design

Designer meets Domain-Driven-Design

サービスデザインからUXデザイン・分析、UIデザインなど、Domain-Driven-Designの事を非エンジニアも知れるようにまとめました。

* Standard Inc & Fablic Incで開催された非エンジニアがDDDに出会うワークショップのスライド資料です。

Transcript

1. Designer meets Domain-Driven-Design Designer meets Domain-Driven-Design Designer meets Domain-Driven-Design σ β Π φ ʔ ͕ υ ϝ Π ϯ Ϟ σ ϧ ۦ ಈ ։ ൃ Λ
   ମ ݧ ͯ͠ ಘ ͨ ஌ ݟ T S U Y O S H I H I G U C H I
2. P R O F I L E 樋 口 剛 T S U Y O S H I H I G U C H I S e r v i c e D e s i g n e r & U I D e v e l o p e r ϑϦʔϥϯεͰελʔτΞοϓ΍৽͍͠ϓϩμΫτͷ
   αʔϏεσβΠϯͱ։ൃɾ࣮૷·Ͱߦ͍ͬͯ·͢ɻ @tyshgc
3. G R O U P Design For User ͜ͷษڧձ͸ɺαʔϏεσβΠϯʹؔΘΔશͯͷਓୡ ͱϢʔβʔͷͨΊʹΑΓྑ͍αʔϏεΛఏڙ͢ΔͨΊ ͷφϨοδڞ༗ͷ৔ॴͱͯ͠͸͡Ί·ͨ͠ɻ
4. Domain-Driven-Designとは何か  実例で見てみる  DDDを経たデザインフローの変化 OOUXやコンポーネント指向へ… 
5.  Domain-Driven-Designとは何？ 
6. Domain-Driven-Designを 体験して感じたコト
7. ドメインモデリングはエンジニア発の ユーザー中心設計だ！ 戦略的ドメインモデル駆動開発は サービスデザインと同じだ！
8. 自分もユースケースとユビキタス言語 を探すようになっていた！
9. しかし… Domain-Driven-Design も 銀の弾丸 ではない ツールやフレームワークを知るのではなく、解決したい本質の部分を学ぶ
10. Domain-Driven-Designを 採用するエンジニアやチームが何を得ようと しているのかが重要
11. では、Domain-Driven-Designを 紐解いてみましょう
12. Domain Driven Design エリック・エヴァンス氏が提唱する ソフトウェアの設計手法 ドメイン駆動設計・開発
13. ιϑτ΢ΣΞઃܭͱ͸ɺ໰୊ղܾͱܭըͷ޻ఔ 移り変わる 概念やステークホルダーの関心事がある
14. ソフトウェアはヒトが扱うもの ソフトウェアはサービスの一部
15. ソフトウェアはヒトが扱うもの ソフトウェアはサービスの一部 ιϑτ΢ΣΞ͕ղܾ͢΂͖໰୊͸ɺ αʔϏεʹؔ܎͢Δ֓೦Λ੔ཧ͢Δաఔ͔ΒಡΈऔΕΔ
16. ֓೦ ෺ࣄʹ͍ͭͯந৅తʹ೺Ѳ͢Δ͞· ϝϯλϧϞσϧ
17. αʔϏεͷར༻ऀ αʔϏεͷఏڙऀ ར༻ऀͷղܾ͍ͨ͠໰୊΍ χʔζͷͨΊʹۀ຿Λ
    ͓͜ͳ͏ ղܾ͍ͨ͠໰୊΍χʔζ͸ ιϑτ΢ΣΞͷத͚ͩʹ
    ͋ΔΘ͚Ͱ͸ͳ͍ αʔϏεͷεςʔΫϗϧμʔ
18. ιϑτ΢ΣΞ͕ղܾ͢΂͖໰୊ αʔϏεͷར༻ऀ αʔϏεͷఏڙऀ εςʔΫϗϧμʔͷ ϝϯλϧϞσϧ͔Β໰୊ͷ֩৺Λநग़Ͱ͖Δ
19. サービスデザインにおける フロントヤードとバックヤードなどの視点と同じだ
20. ؔ܎͢Δώτͷ໰୊ղܾͱͣͬͱ෇͖߹͏ͨΊʹɺ ֓೦ϞσϧʹԊͬͯΦϒδΣΫτࢦ޲Ͱ ։ൃʢઃܭɾ࣮૷ʣΛਐΊΔ Domain Driven Design
21. なぜ、Domain-Driven-Design？ DDDへの変遷
22. ιϑτ΢ΣΞ։ൃ͸ৗʹมߋͱεϐʔυͱͷઓ͍
23. ઃܭͷͳ͍ঢ়ଶͰͷ։ൃ͢ΔͱͲ͏ͳΔ͔ʁ
24. มߋʹΑΔӨڹൣғ͕޿͘ͳ͍͖ͬͯ อक͕೉͘͠ͳΔ ࣅͨಉ͡ػೳͷίʔυ͕൙ཞ͍ͯ͠Δ UIͱίΞʹͳΔίʔυ͕ࠞࡏɺUIมߋͷ౓ʹӨڹΛड͚Δ = SmartUIʢརޱͳUI / ը໘ۦಈʣ σʔλϕʔε΁ͷϦΫΤετ΍มߋͷίʔυ͕఺ࡏ͍ͯ͠Δ
25. ࢓༷υΩϡϝϯτ͸ ௥͍͔ͭͳ͍ Өڹൣғ͕ଟͯ͘ ࠞཚ͕ى͜Δ
26. ソフトウェア開発はサービスの成長スピードに 合わせて柔軟に寄り添い続ける必要がある メンタルモデルを基本にした設計に則って、 コードを言語として人がわかるように書こう！
27. どうやってやる? HOW
28. 設計を正しく行うために サービスの概念 を正しく知ろう 概念を知るために ユースケース を探そう
29. ユビキタス言語を抽象化し ドメインモデル を抽出しよう ユースケースから ユビキタス言語 を定義しよう
30. ドメインモデルをオブジェクト指向の クラスモデル にしていこう ドメイン層と 技術的処理やUI層など 責務 を分けよう
31. ֓೦͕ίʔυͰදݱ͞Εɺ໾ׂ͝ͱʹߏ଄Խ͞ΕΔ ίʔυΛॻ͘ = Lean & Design
32. ドメイン？ ユースケース？ ユビキタス言語？責務? WHAT
33. υϝΠϯ サービスのコンテキスト上にある 概念の集まり アカウントという概念はコンテキスト によって異なる。 銀行サービスという文脈で見ると口座 という意味になるが、アプリという文 脈で見るとユーザー情報となる。
34. Ϣʔε έʔε サービスに関係するアクターの それぞれの活動や行動 アクターは利用者、提供者、 システムまで含まれる。 それらのタスクを主語・述語レ ベルで表現できるような単位の もの。
35. ϢϏΩλε ݴޠ ユースケースに存在する 言葉の定義 = メンタルモデル ユビキタス言語とは、 どこでも使える言語のこと。 開発時の普段の会話から コードの命名にも使われる。
36. ੹຿ ドメインモデルを様々な実装上の 都合などから隔離すること サービスの概念や振る舞いだけ をコードに置き換えたものが ドメイン層。 それ以外については、役割ごと に別の層に置いていく。
37.  実例で見てみる 
38. レストランの接客業務 を例にする
39. アクターとユースケースを 探ってみる
40. ΞΫλʔ αʔϏεʹؔ܎ͨ͠׆ಈʹొ৔͢Δਓ෺΍γεςϜ
41. ϨετϥϯαʔϏεͷΞΫλʔ ϨετϥϯͷαʔϏεΛར༻ɻ ϗʔϧελοϑ ઀٬୲౰ͷελοϑɻ઀٬࣌ʹ୺຤Λ࢖༻ ͯ͠஫จΛड෇͚Δɻ ར༻٬ ਥ๪ελοϑ ௐཧ୲౰ͷελοϑɻ POS ൢച࣌఺৘ใ؅ཧγεςϜɻ୺຤͔Β஫จ Λड͚෇͚ɺਥ๪΁प஌ͨ͠Γɺܾࡁͷ؅ ཧΛߦ͏ɻ
42. Ϣʔεέʔε ΞΫλʔͦΕͧΕͷλεΫ ओޠʢΞΫλʔʣ+ ड़ޠʢಈ࡞΍ঢ়ଶʣ ͳΔ΂͘γϯϓϧͳจষʹ͢Δ
43. ϨετϥϯαʔϏεͷϢʔεέʔεʢҰ෦ൈਮʣ ར༻٬͸ɺೖళ͢Δ ϗʔϧελοϑ͸ɺςʔϒϧ΁Ҋ಺͢Δ ར༻٬͸ɺϝχϡʔ͔Β඼໨ΛબͿ ར༻٬͸ɺϗʔϧελοϑΛݺͿ ར༻٬͸ɺر๬ͷ඼໨Λ஫จ͢Δ ϗʔϧελοϑ͸ɺ୺຤ʹ඼໨Λೖྗ͢Δ ୺຤͸ɺ஫จ඼໨ͷࡏݿΛݮΒ͢
44. Ϣʔεέʔε͸ਤʹͯ͠΋ྑ͍ ڞ༗Ͱ͖ͯΘ͔Ε͹ͳΜͰ΋ྑ͍ ސ٬ ϗʔϧελοϑ ୺຤ ඼໨ΛબͿ ඼໨Λ୳͢ ඼໨ΛબͿ ஫จΛ֬ఆ͢Δ ஫จΛ͢Δ γεςϜ ʢ104ʣ
45. ϢϏΩλεݴޠ Ϣʔεέʔεʹଘࡏ͢Δݴ༿ͷఆٛΛ͢Δ ྫʣϨετϥϯͱ͸ɺ஫จͯ͠ҿ৯͢Δ৔ॴͩ
46. Ϣʔεέʔε͔Βݴ༿Λर͍ͬͯ͘ ར༻٬͸ɺೖళ͢Δ ϗʔϧελοϑ͸ɺςʔϒϧ΁Ҋ಺͢Δ ར༻٬͸ɺϝχϡʔ͔Β඼໨ΛબͿ ར༻٬͸ɺϗʔϧελοϑΛݺͿ ར༻٬͸ɺر๬ͷ඼໨Λ஫จ͢Δ ϗʔϧελοϑ͸ɺ୺຤ʹ඼໨Λೖྗ͢Δ ୺຤͸ɺ஫จ඼໨ͷࡏݿΛݮΒ͢ テーブル メニュー 品目 注文 在庫
47. ϨετϥϯαʔϏεͷϢϏΩλεݴޠʢҰ෦ൈਮʣ ੮͕ෳ਺͋Δ΋ͷɻςʔϒϧ୯ҐͰ஫จΛ ड͚෇͚Δɻ ϝχϡʔ ඼໨͕ΧςΰϦ͝ͱʹϦετ͞Εͨ΋ͷɻ ςʔϒϧ ඼໨ ྉཧ঎඼΍ҿྉ঎඼ɺηοτɾίʔεͳͲ ͷ঎඼ͷࣄɻ ஫จ ඼໨ΛબΜͰਥ๪ͰௐཧΛ࢝ΊΔ͜ͱɻ ·ͨ୅͕ۚൃੜ͢Δ͜ͱɻ
48. ϢϏΩλεݴޠΛ୳Δ࣌ͷϙΠϯτ ݴ༿ͷఆٛʹҧ࿨ײΛ֮͑ͨΒɺ αʔϏεͷ஌ࣝΛ࣋ͭਓ΍ར༻ऀʹώϠϦϯάΛߦ͏ ҧ࿨ײͷ౓ʹ܁Γฦ͠ߦ͏ ΤϯδχΞ͸ίʔυॻ͖ͳ͕Βҧ࿨ײΛ୳͍ͬͯΔ
49. このコードは、 レストランの "品目" というモデルを 表現している例
50. 品目（MenuItem）は… 品目名があり、 それぞれ一意なIDが 決められている。 また、値段が決められており、 数に限りがある（在庫がある）。
51. 品目（MenuItem）の 振る舞い（ロジック） 品目には在庫があり、在庫は管 理されるもの。 • 品目の在庫から選ぶ sele ct( ) • 品目の在庫を戻す cancel( )
52. ඼໨ɿΦϜϥΠεΛ࡞Δ ඼໨ͱ͍͏ந৅తͳΦϒδΣΫτʢΫϥεΦϒδΣΫτʣΛ ΦϜϥΠεͱ͍͏࣮ମʹ͍ͯ͠Δ
53. これが初歩の段階。 このコードや他のモデルを整理したり、責務を移譲したり とイテレーションをすることで違う表現が見えてくる →リファクタリングへ ֓೦Λ ϞσϦϯά Ϟσϧ Ϋϥεͷਫ਼ࠪ ϢϏΩλεݴޠ ݟ௚͠ ੹຿ͷҠৡ
54. まとめ
55. Domain Driven Designの本質は ユビキタス言語 = メンタルモデル ߏ଄ԽͷΞʔΩςΫνϟ͸։ൃࣄ৘ʹ߹Θ͍ͤͯ͘
56. ϢϏΩλεݴޠΛ࢖͏͜ͱͰΠϝʔδͷᴥᴪΛݮΒ͢ ֓೦ͷந৅ԽʹΑͬͯαʔϏεͷຊ࣭Λڞ༗͢Δ ίʔυΛ࢓༷υΩϡϝϯτʹঢ՚ͤ͞อकੑɾมߋ༰қੑ Λ޲্ͤ͞Δ ϝϯλϧϞσϧ͔ΒυϝΠϯϞσϧΛཧղ͢Δ͜ͱͰ Ϣʔβʔத৺ͷιϑτ΢ΣΞΛ࡞Δ ͕͜͜Ұ൪ॏཁ
57.  DDDを経たデザインフローの変化  OOUXやコンポーネント指向…
58. 基本的には前から やってた感はあるけど…
59. ϢʔεέʔευϦϒϯʹͳͬͨ ユーザーストーリーよりもスコープが小さいので 主観的にユーザーを想像することが少なくなった。 ユースケース分析すると時間の流れも把握できる。 導線設計やデータフローの参考にするようになった。
60. ユーザーAは 観光地までの アクセス方法を 知りたい ユーザーCは オススメの 飲食店の場所を 調べる ユーザーBは 空港までの 乗り換え案内 を見たい ユーザーは 経路を調べる ユーザーは 施設情報を 調べる 各論 抽象論
61. νʔϜϝϯόʔͰूΊͨϢʔεέʔεΛ࣌ܥྻʹεϓϨουγʔτʹ·ͱΊͨΓ
62. ϝϯλϧϞσϧΛఆٛ͢ΔΑ͏ʹͳͬͨ 画面単位でのデザインを行わず、メンタルモデルに 沿ったコンポーネント設計をするようになった。 モデルからコンポーネントの属性値や振る舞いを見つ ける。またGUI依存するものや表示するだけのものなど 責務ごとに分けてなるべく疎結合を目指す。
63. 品目リスト（配列）を渡す メニューコンポーネント 品目コンポーネント 品目名、価格、注文数などを渡す
67. ユースケースや メンタルモデルから コンポーネント を定義する OOUXͱ͍͏ͷΛఏএ͍ͯ͠Δਓ͕͍Δ Object-Oriented-UX http://alistapart.com/article/object-oriented-ux
68. Domain Driven Designからの学び メンタルモデルとユースケースとても大事 σβΠϯ΋֓೦ʹԊΘͤͯɺ࠷ऴతʹ͸ϑϩϯτΤϯυͷίʔυʹ
69. Thank you!