脱軽量DDDを実践する開発プロジェクトの事例 / Examples of development projects that practice de-lightweight DDD

Yappli Tech Conference 2023 登壇資料

connpass:
https://yappli.connpass.com/event/295001/

セッション動画（YouTube:）
https://youtu.be/DNTEAaQ-_ys?si=GDvj_x9GagVwKMJS

Transcript

1. 脱軽量DDDを実践する 開発プロジェクトの事例
2. Speaker プロダクト開発本部 サーバーグループ 窪 田 修 Kubota Shu キャリアスタートはReact, React Native。ヤプリに 2022年5 月 にサーバーサイドエンジニアとして 入 社。 特に、DDD、hooks設計、Redux設計が好き。ヤプリ では主にGo, PHPでのサーバーサイドアプリケーショ ンの設計, 開発を担当。 一 部インフラの整備、Webフ ロントエンドの開発もたまにする。業務ではAWSがほ とんどだったが、最近Google Cloudの資格をとって Google Cloudにハマりつつある。
3. Agenda Yappliのシステムの概要 なぜDDDで設計したのか 軽量DDDになるという課題 軽量DDDになる要因 脱軽量DDDのアプローチ PJの事例 実践モデリング 戦術的DDDの知 見 まとめ 00 01 02 03 04 05 06 07 08
4. 今 日 の話のサマリー YappliのサーバーサイドのシステムはDDDで設計されている。 一方 で軽量DDDになるという課題がある。 そこで1開発PJで脱軽量DDDの設計事例を作った。 プロダクト全体の脱軽量DDDの取組みを継続している。
5. 00 Yappliのシステムの概要
6. 0 0 Yappliのシステムの概要 システムの概略
7. 0 0 Yappliのシステムの概要 システムの概略 DDDͰઃܭ
8. 0 0 Yappliのシステムの概要 システムの概略 DDDͰઃܭ
9. 01 なぜDDDで設計したのか
10. զʑͷ໨త͸Կ͔ʁ
11. ៉ྷͳγεςϜΛ࡞Δ͜ͱ
12. ៉ྷͳγεςϜΛ࡞Δ͜ͱ ビジネス的価値を継続的に届ける システムを作ること
13. ΋͏গ͠ϒϨΠΫμ΢ϯ͢Δͱ
14. ໨త = ϝϯςφϯεੑ͕ߴ͘ɺ εέʔϧ͢ΔγεςϜΛ࡞Δ
15. खஈͱͯ͠ෳࡶͳ࢓༷ͷઃܭʹదͨ͠ DDDΛ࠾༻ͨ͠
16. 01 なぜDDDで設計したのか 今 日 の話の前提知識 • エリック ・ エヴァンスのドメイン駆動設計 • 実践ドメイン駆動設計 • ドメイン駆動設計モデリング/実装ガイド • ドメイン駆動設計 入門
17. Domain Driven Design(DDD)とは • ドメインモデルを中 心 とした設計パターン • ドメイン知識そのものをコード上に表現することを 目 指す 01 なぜDDDで設計したのか
18. DDDの得意なこと • 複雑な仕様をモデルの振る舞いとして表現できる • ドメイン知識そのものをソースコードとして表現できる • 結果的に複雑なソフトウェアを継続的に誰でもメンテナンスで きるようになる 01 なぜDDDで設計したのか
19. DDDの得意なこと • 複雑な仕様をモデルの振る舞いとして表現できる • ドメイン知識そのものをソースコードとして表現できる • 結果的に複雑なソフトウェアを継続的に誰でもメンテナンスで きるようになる →ϊʔίʔυͰΞϓϦΛ࡞ΕΔYappliͷCMSͷػೳ͸ଟ͘ɺ࢓༷͸ඇৗʹෳࡶͰ ͜ΕΛ࣮ݱ͢Δखஈͱͯ͠DDDͰͷઃܭ͸ྑͦ͞͏ 01 なぜDDDで設計したのか
20. ҰํͰDDDʹ͸σϝϦοτ΋͋Δ
21. DDDの苦 手 なこと • パフォーマンス • ソースコードの記述量が多い • 局所的な開発スピードは遅い 01 なぜDDDで設計したのか
22. DDDが不向きなアプリケーションもある • 仕様が単純なシステム ex) 単純なCRUDだけのブログサイト • インフラが主役のシステム ex) 株の売買アプリケーション 01 なぜDDDで設計したのか
23. そしてDDDのメリット、デメリット 比 較の後 YappliはDDDを採 用 した
24. DDDΛ࠾༻ͨ͠΋ͷͷ՝୊͕࢒͍ͬͯͨ
25. 02 軽量DDDになるという課題
26. 軽量DDDとは • DDDの 一 部のみの考え 方 を取り 入 れたアプローチ • コンテキストの境界の定義を省略するパターンが多い • ドメイン知識のコード上での表現が達成できない 0 2 DDDで設計する上での課題 軽量DDD = 技術的パターンのつまみ 食 い
27. 軽量DDDあるある • entity, repository, useCase, serviceを作って満 足 する • ドメインエキスパートはいない • モデルはエンジニアの裁量で作る • コンテキストの境界が定義されていない • 集約の定義がなんとなくになる 0 2 DDDで設計する上での課題
28. ͳͥܰྔDDDͩͱμϝͳͷ͔?
29. 軽量DDDの 欠 点 最 大 の 欠 点は 「知識をコード上で表現する」を実現できないこと = 複雑な仕様を表現できない = メンテナンス性の 高 いスケールするシステム設計ができない 0 2 DDDで設計する上での課題
30. 軽量DDDの 欠 点 最 大 の 欠 点は 「知識をコード上で表現する」を実現できないこと = 複雑な仕様を表現できない = メンテナンス性の 高 いスケールするシステム設計ができない 0 2 DDDで設計する上での課題 →YappliͷߴػೳCMSͷෳࡶੑͷ௿ݮʹߩݙ͢ΔҰ൪ͷDDDͷ௕ॴ͕ੜ͔͖͠Εͳ͍
31. 軽量DDDの 欠 点が露呈する例1: DB = entity ほぼDBモデル = entityになる 現実世界に存在しない概念がentityとして存在。 エンジニアだけでモデリングするとやりがち。 ただ記述量が増えるだけ。 0 2 DDDで設計する上での課題 →ԾʹDBϞσϧ=entity͕࠷దͳΒ͹ɺDDD͸࠾༻͠ͳ͍ํ͕ྑ͍
32. 軽量DDDの 欠 点が露呈する例2: 集約が歪む 集約設計を怠り、後から集約の 一 部を扱うmethodがrepositoryに追加される (集約設計は戦術的DDDの話ではあるが、戦略的DDDを省略すると影響を受けやすい) 0 2 DDDで設計する上での課題 →υϝΠϯΤΩεύʔτͷߟ͑ͱζϨ࣮ͨ૷Λ͢Δͱ࢓༷௥Ճ࣌ʹ௧͍໨ʹ͋͏͜ͱ͕ଟ͍
33. Ͱ͸ɺͳͥܰྔDDDʹͳΔͷ͔?
34. 03 軽量DDDになる要因
35. 軽量DDDに陥る理由 • ドメインエキスパートとのコミュニケーションのコストが 大 き い • 答え合わせができないモデリングは体系化しにくい 03 軽量DDDになる要因
36. 軽量DDDに陥る理由 • ドメインエキスパートとのコミュニケーションのコストが 大 き い • 答え合わせができないモデリングは体系化しにくい 03 軽量DDDになる要因
37. コミュニケーションコストがかかる ドメインエキスパートとエンジニアは違う部署 ・ チームにいるこ とが多い。 また、お互いに忙しい(スタートアップあるある)。 実装時間を削るわけにはいかないので、結果的にドメイン知識を 共有してモデリングする時間が失われるパターンはよくある。 03 軽量DDDになる要因
38. 軽量DDDに陥る理由 • ドメインエキスパートとのコミュニケーションのコストが 大 き い • 答え合わせができないモデリングは体系化しにくい 03 軽量DDDになる要因
39. モデリングには答えがない • ドメイン知識は各プロダクト固有のもの • Yappliのモデリングの答えが世の中にあるわけではない • 体系化できない→だから戦略的DDDの本は少ない 03 軽量DDDになる要因
40. エンジニアの性質も ・・・ ？ 技術指向の開発者は、 自 分の専 門 スキルを発揮できる、定量化可 能な問題を楽しむものだ。ドメインに関する作業は 面 倒な上に、 入 り組んだ新しい知識を 大 量に必要とするが、そうした知識は開 発者にとって、コンピュータ科学者としての能 力 を向上させるも のではないように 見 えるのだ。(ドメイン駆動設計 第1部より) →ΤϯδχΞ͸ఆྔԽͰ͖Δ໰୊=ମܥԽ͞ΕධՁՄೳͳ໰୊͕޷͖ →ٯʹɺυϝΠϯϞσϦϯάͷΑ͏ͳ౴͕͑ग़ͤͳ͍ →݁ՌɺઓུతDDD͸ஔ͖ڈΓʹ͞ΕɺܰྔDDDʹؕΔ 03 軽量DDDになる要因
41. Ͱ͸ɺͲ͏΍ͬͯ୤ܰྔDDD͢Δͷ͔?
42. 04 脱軽量DDDのアプローチ
43. 演繹的アプローチ vs 帰納的アプローチ • 演繹的アプローチ 体系化された知識を当てはめて設計していく • 帰納的アプローチ 事例をいくつか作って、後に知識を体系化していく 04 脱軽量DDDのアプローチ
44. 演繹的アプローチ vs 帰納的アプローチ • 演繹的アプローチ 体系化された知識を当てはめて設計していく • 帰納的アプローチ 事例をいくつか作って、後に知識を体系化していく 04 脱軽量DDDのアプローチ →ؼೲతʹΞϓϩʔν͢Δͷ͕ྑͦ͞͏ɻίϛϡχέʔγϣϯɺϞσϦϯά౳ͷ౴͕͑ͳ͍໰୊ ʹରͯ͠͸ɺෳ਺ࣄྫ͔ΒYappliಠࣗͷମܥԽ͞Εͨ஌ࣝΛ࡞͍͚ͬͯ͹ྑ͍ͱ͍͏ൃ૝ɻ
45. ͭ·Γɺ·ͣ1ݸɺ୤DDDͷࣄྫΛ࡞Δ
46. 05 PJの事例
47. PJの概要 CMS操作者の権限管理の仕組み を導 入 するPJ 0 5 PJの事例
48. 作る機能の概要 ΧελϜϩʔϧͱ͍͏֓೦Λ࡞ΔɻΧελϜϩʔϧͰฤूͰ͖ΔػೳΛઃఆͰ͖Δɻ ֤ϝϯόʔʹΧελϜϩʔϧΛׂΓ౰ͯͯɺฤूͰ͖ΔείʔϓΛ੍ޚͰ͖Δɻ 0 5 PJの事例
49. PJ構成メンバーのイメージ • ディレクター • デザイナー2 人 • フロントエンジニア1 人 • サーバーサイドエンジニア3 人 • QAエンジニア、SREも関わる 0 5 PJの事例
50. 06 実践モデリング
51. ユビキタス 言 語の定義 06 実践モデリング • PJチーム内で 言 葉の定義をした • 仕様策定と同時に 行 った • Figma上で議論した • 最終的には仕様書に落とされた
52. ユビキタス 言 語の定義 • PJチーム内で 言 葉の定義をした • 仕様策定と同時に 行 った • Figma上で議論した • 最終的には仕様書に落とされた υϝΠϯΤΩεύʔτ + ΤϯδχΞͰݴ༿Λἧ͑Δ͚ͩͰɺ ίϯςΩετͷڥք͸ܾ·Δɻ 06 実践モデリング
53. モデルの定義 境界づけられたコンテキスト内にドメインモデ ルを定義する。 【決まること】 モデル名, 多重度, 大 体のproperty名 【決まらないこと】 関連モデルの表現property 06 実践モデリング
54. 集約を決める必要がある 同じ集約で設計するパターン 別集約で設計するパターン 06 実践モデリング
55. 集約を正しく理解する 集約の定義: transaction整合性をとりたいEntityのグループ 集約の決め 方 は完全にシステム都合 (ドメインエキスパートは登場しない) VS どちらを選択するかはtransaction整合性をとれるかで判断する つまり集約を決めるためにDB設計をする必要がある 06 実践モデリング
56. 集約を決めるためのDB設計 登場したドメインモデルをもとにDB設計をする 必要な情報をインフラ都合で最適化したDBモデルを作る 06 実践モデリング
57. 集約を決める • memberとcustom_roleはそれぞれ別useCaseで独 立 して扱いたい • tabbarはメインDBと違うサーバで管理していてtransaction整合性は不可 06 実践モデリング
58. モデルの定義(再掲) コンテキスト内のドメインモデル 【決まること】 モデル名, 多重度, 大 体のproperty名 【決まらないこと】 関連モデルの表現property 06 実践モデリング
59. モデルの定義(再掲) コンテキスト内のドメインモデル 【決まること】 モデル名, 多重度, 大 体のproperty名 【決まらないこと】 関連モデルの表現property →集約が決まったのでもう決められる 06 実践モデリング
60. 最終的なドメインモデル図 コンテキスト内のドメインモデル 【決まること】 モデル名, property, 多重度, 集約 06 実践モデリング
61. ͜͜·Ͱ͘Δͱentity, repository͸ ΋͏࣮૷Ͱ͖Δ!!
62. Entityのコード Entityを表すstructの定義とconstructorは実装でき 06 実践モデリング
63. Repositoryのコード 1集約に対して1repositoryが定義され 06 実践モデリング
64. ͜ͷޙɺentityͷ֤ϝιουͱuseCaseΛ ࣮૷͍ͯ͘͜͠ͱʹͳΔ (ࠓճ͸লུ)
65. 07 戦術的DDDの知 見
66. ઓུతDDD͔Β࣮ફ͍ͯ͘͠ͱ ઓज़తͳ෦෼Ͱ΋஌ݟ͕ಘΒΕΔ
67. 境界づけられたコンテキストの開発 07 戦術的DDDの知 見 1個の境界づけられたコンテキストは • 1サブドメイン • 1マイクロサービス • 1 githubリポジトリ • 1開発チーム で扱われることが多い。
68. モノリス × 複数サブドメイン 一方 でYappliではあらゆるサブドメインが 一 つのGoのソースコ ードで開発されている 07 戦術的DDDの知 見
69. サブドメインをGoのpackageで表現する 1サブドメインを1packageで表現する この辺りは 言 語仕様との相談になる DDD視点のサブドメインと 言 語仕様としてのpackageを混在させた点は妥協点 07 戦術的DDDの知 見
70. 他サブドメインとのやりとり 例えばあるサブドメインから 権限管理コンテキスト内の サブドメインに問い合わせる場合、 オニオンの外側同 士 でやり取りはす る。 07 戦術的DDDの知 見
71. 呼び出す側 07 戦術的DDDの知 見 まるで外部APIに問い合わせるかの ように同github repositoryで定義さ れているhandlerにアクセスする 他サブドメインとのやりとり
72. 呼び出される側 07 戦術的DDDの知 見 アクセスされるhandlerにアクセス する 他サブドメインとのやりとり
73. 08 まとめ
74. まとめ • Yappliのドメイン知識は深く、DDDを採 用 した • 一方 で、DDDの良いところを 生 かしきれていない課題もあった • まずPJ事例を作ることで脱軽量DDDを 目 指した • ユビキタス 言 語定義、ドメインモデリング、実装までの 一 連の フローを実現できた 08 まとめ
75. ՝୊͸࢒͞Ε͍ͯΔ
76. 課題に対してやりたいこと • 継続した脱軽量DDDの事例作り • 事例から得た本には書いていないYappli独 自 の知識の体系化 • サーバーチーム全体でのコーディングの統 一 化 • 継続的なリファクタリング 08 まとめ
77. ՝୊͸͋Δ͕ɺղܾͰ͖Δ؀ڥ΋͋Δ
78. 重要度: 高 , 緊急度: 低 への意識 重要だが緊急度が低いと着 手 されないことが多い。 ヤプリの開発組織では左上領域を 大 切にする 文 化がある。 →結果的に戦略的DDDに真正 面 から取り組むことができた。 08 まとめ