スタートアップでDDDを始めた時の困難

このプレゼンテーションでは、スタートアップ企業でDomain-Driven Design(DDD)を導入する際の困難と、チームの状況に応じてDDDの導入方法をグラデーションをつけて用いる戦略について説明しています。
主な内容は以下の通りです:
会社の概要と自己紹介
DDDの戦略的導入の理由: ドメインの拡大、ドメイン知識不足の新入社員増加
DDDの主要要素(ドメインモデリング、境界付けられたコンテキスト、コンテキスト間の関係、システムの分割・統合)に対するMaxプランとグラデーション導入の比較
グラデーション導入のデメリット
グラデーション導入の全体的なアクション項目のまとめ
結論: チームの状況に合わせてDDDの導入をグラデーションさせる
要約すると、DDDの完全導入は難しいため、チームの状況に応じてグラデーション導入を行い、徐々にDDDの要素を取り入れていくアプローチが提案しています。

Transcript

1. スタートアップでDDD を始めた時の困難
2. 自己紹介
3. 所属 株式会社TechBowl 住んでるところ 東京 何やってる？ 「TechTrain 」というサービスで反復横跳びし続けている 何でも屋さん(Laravel, Next.js, AWS, etc...) 趣味 お酒( よく溺れる) サウナ 読書 2024-05-13 | スタートアップでDDD を始めた時の困難 3
4. TechTrain エンジニア教育+Direct スカウトのサービス。 Coding Stoic をテーマにちゃんとコードを書いていこう ね！というメンターが多めのエンジニアを育てるための サービスです。 2024-05-13 | スタートアップでDDD を始めた時の困難 4
5. 一緒に働いてくれる人を探しています！ 1. バックエンドエンジニア(Laravel + DDD) 2. フロントエンドエンジニア(Next.js with TypeScript) 3. TechTrain のメンター -> 筋がいい人なら教えたいぜ！ 2024-05-13 | スタートアップでDDD を始めた時の困難 5
6. 結論 2024-05-13 | スタートアップでDDD を始めた時の困難 6
7. チームの状態に合わせてグラデーションをつける 2024-05-13 | スタートアップでDDD を始めた時の困難 7
8. 前提 職種を超えて、信頼を獲得していること、しようとしていること ドメインエキスパートが増えるように施策は打っておくこと 業務委託を含めたチームが急激に増え始めたタイミングであること 2024-05-13 | スタートアップでDDD を始めた時の困難 8
9. なぜ戦略的DDD の導入だったのか？ 2024-05-13 | スタートアップでDDD を始めた時の困難 9
10. ドメインが広くなった・・・ 2024-05-13 | スタートアップでDDD を始めた時の困難 10
11. ドメイン知識を全く知らない人の入社が増えた 人材業界、ダイレクトリクルーティング、エンジニアについて知らないぞ？ 飲み屋出身だから本当に何も知らないぞ？ 2024-05-13 | スタートアップでDDD を始めた時の困難 11
12. で、ここからちゃんと「チームの状態に合わせてグラ デーション」は何をやったのか？ 2024-05-13 | スタートアップでDDD を始めた時の困難 12
13. 全体のMax プランのアクション エンジニアサイドビジネスサイド関わりなく 1. 全員がドメインの知識を習熟し、顧客が誰かを定義している 2. 用語の揺れなどがあれば、用語集などに編集に行く 3. ユースケースなどの定義に全員が参加して進める 2024-05-13 | スタートアップでDDD を始めた時の困難 13
14. まぁ工数的に難しいことが多い 2024-05-13 | スタートアップでDDD を始めた時の困難 14
15. グラデーションをつけて導入していく 2024-05-13 | スタートアップでDDD を始めた時の困難 15
16. 戦略的設計の主要な要素 △ ドメインモデリングとドメインの識別 境界づけられたコンテキストの設定 コンテキスト間の関係の管理 システムの分割・統合( コンテキストのとも言えるかも) 2024-05-13 | スタートアップでDDD を始めた時の困難 16
17. ドメインモデリングとドメインの識別 Max プラン 次のことを関係者全員で行う コアドメイン、サブドメインの特定 ドメインモデル図の作成 2024-05-13 | スタートアップでDDD を始めた時の困難 17
18. ドメインモデリングとドメインの識別 グラデーション ドメインモデル図などに揺れや漏れがある時にエンジニアが収束させにいく 最低限のビジネスサイドとエンジニアでドメインモデル図の作成 ステークホルダーへの確認と修正 2024-05-13 | スタートアップでDDD を始めた時の困難 18
19. どの時点で見直す？ システムも含めて分割を行い、関係者の分割をできたら見直しを入れる 2024-05-13 | スタートアップでDDD を始めた時の困難 19
20. 境界づけられたコンテキストの設定/ コンテキスト間の 関係の管理 Max プラン 2024-05-13 | スタートアップでDDD を始めた時の困難 20
21. 境界づけられたコンテキストの設定/ コンテキスト間の 関係の管理 グラデーション 最低限のエンジニアとビジネスサイドで定義して勝手にやれるうちは、あまり明確に ドメインエキスパートが抑えこみに行かない 2024-05-13 | スタートアップでDDD を始めた時の困難 21
22. 境界づけられたコンテキストの設定/ コンテキスト間の 関係の管理 いつ見直すのか？ 勝手にチームでこれができなくなってきた時にドメインエキスパートがここを厳しめ にちゃんとやるひつようが出てくると理解 2024-05-13 | スタートアップでDDD を始めた時の困難 22
23. システムの分割・結合 Max プラン Micro サービスなどにして分割していく 2024-05-13 | スタートアップでDDD を始めた時の困難 23
24. グラデーション ユースケースをどのドメイン領域で誰が何をやっているのか？などを明確に分け て進めている 2024-05-13 | スタートアップでDDD を始めた時の困難 24
25. いつ見直すのか？ 分けないとアウトカムが明らかに出ないようになってきている状態、認知負荷を 確実に超えてきたなと言える状態になってきた 2024-05-13 | スタートアップでDDD を始めた時の困難 25
26. このグラデーションによるデメリット チームのカルチャーによって、アウトカムではなくアウトプットへの執着になり うる エンジニアとビジネスサイドの確認、連携がうまく機能しない可能性がある 2024-05-13 | スタートアップでDDD を始めた時の困難 26
27. 全体のグラデーションとしてのアクションのまとめ 1. 最低限の関係者が集まり、ドメインについての情報を集約と深掘り 2. 集約した情報をもとにユースケースを整理し、共有 3. ドメインモデル図など必要なドキュメントをエンジニアが起こす 4. 用語集は気づいたタイミングで職種関係なく更新 5. ドメインエキスパートがそれぞれドメイン知識を移植するための勉強会を開く 2024-05-13 | スタートアップでDDD を始めた時の困難 27
28. 結論 2024-05-13 | スタートアップでDDD を始めた時の困難 28
29. チームの状態に合わせてグラデーションをつける 2024-05-13 | スタートアップでDDD を始めた時の困難 29
30. 以降は参考です！ 2024-05-13 | スタートアップでDDD を始めた時の困難 30
31. 1. DDD をどのように考えているのか 2024-05-13 | スタートアップでDDD を始めた時の困難 31
32. 構成要素 ユビキタス言語 ドメインエキスパート 境界づけられたコンテキスト 2024-05-13 | スタートアップでDDD を始めた時の困難 32
33. ユビキタス言語 1. 業界についての情報 2. 実際の運用で利用する情報 3. 社内における独自の用語 2024-05-13 | スタートアップでDDD を始めた時の困難 33
34. ドメインエキスパート 1. 業界の事情を網羅している 2. ソフトウェアとドメイン知識を行使する現場との橋渡し 2024-05-13 | スタートアップでDDD を始めた時の困難 34
35. 境界づけられたコンテキスト 同じ用語を別の使い方になっていないか？ということが重要 現場で揺れ始めているのを感じたら気づいたエンジニアから分割or 統一に向かう 2024-05-13 | スタートアップでDDD を始めた時の困難 35
36. 前提となるコンテキスト1: ドメインの領域が広いor 複数ある 1. TechTrain( エンジニア教育のプラットフォーム) 2. DirecTrain( ダイレクトリクルーティング) 3. AgenTrain( 人材紹介) 3 つの業界をまたがっていると言っても良い。 2024-05-13 | スタートアップでDDD を始めた時の困難 36
37. 前提となるコンテキスト2: チームのメンバー状態の急激な変化 1. 業務委託のエンジニア 2. 業務委託のビジネスサイド 3. 正社員のエンジニア 4. 正社員のビジネスサイド 2024-05-13 | スタートアップでDDD を始めた時の困難 37
38. 2. なぜDDD を取り入れようと思ったのか 当時概念が多くなっていたにも関わらず何もまとめていなかった 事業の種類も増え、ビジネスサイドのエンジニアサイドの人数が増えていた ビジネスサイドとエンジニアサイドで用語の分離が起こり始めていた 2024-05-13 | スタートアップでDDD を始めた時の困難 38
39. そこに現れてくれたDDD を実践している人の登場 最初のカジュアル面談のタイミングで概念の図を一緒に起こした その時点で、これからも概念が大きく増えて横断的に利用される実感が湧いたた め、DDD をチーム的に導入することに決めた この時点で、戦術的実装についてはほとんど検討していなかった 2024-05-13 | スタートアップでDDD を始めた時の困難 39
40. 概念をまとめるための細かいツールの変遷についてはこちらのブログを見ていただけ ますと・・・！ DDD × Whimsical で快適モデリングライフ！ 2024-05-13 | スタートアップでDDD を始めた時の困難 40
41. 3. 実際にどこまでワークしているのか、していないの か 2024-05-13 | スタートアップでDDD を始めた時の困難 41
42. 戦略的設計の主要な要素 ️ ドメインモデリングとドメインの識別 境界づけられたコンテキストの設定 コンテキスト間の関係の管理 コンテキストの統合 2024-05-13 | スタートアップでDDD を始めた時の困難 42
43. 境界づけられたコンテキストの設定 なぜこれが必要か？ 同じ言葉を使っているのに別の使われ方をしているということが出てきたら、こ ちらを丁寧にやっていく必要があると思うが、今は必要ないと判断。 むしろ今やってしまうと、同じコンテキストで扱えているのに別で管理する必要 性に迫られ、必要のない工数が増える。 今は境界づけるようなものはほとんどない。一部あるが、チームで認識をとって 必要になった時にコンテキストを最低限分割することができている。 勝手にチームでこれができなくなってきた時にドメインエキスパートがここを厳 しめにちゃんとやるひつようが出てくると理解。 2024-05-13 | スタートアップでDDD を始めた時の困難 43
44. システムの分割・結合 これはやってない というかエンジニアを採用できないとできない。 今ドメインの事情が諸々絡み合ってるので、システム自体の分割( 特にバックエン ド) が難しい。 ユースケースを変に統一しないことで割り切っている。 いろんなところで使われるからこそ、どこで誰かと言うところまで分けて定 義している システムは分割していないが、その分アプリケーションレイヤーを細かく区 切って誰が何をするのかがわかりやすいようにしている。（戦術が少し入っ てしまうんだけど） サブドメインはやってない ドメインがデカくなった時にしっかり分割を進めていけば、それが自然にサ ブドメインになるんじゃね？ またサブドメインを跨ぐと、認知限界を超えてくると考えているので、一旦 2024-05-13 | スタートアップでDDD を始めた時の困難 44
45. 結論 2024-05-13 | スタートアップでDDD を始めた時の困難 45
46. チームの状態に合わせてグラデーションをつける 2024-05-13 | スタートアップでDDD を始めた時の困難 46
47. 2024-05-13 | スタートアップでDDD を始めた時の困難 47