ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
•
7 likes•4,144 views
BtoB SaaSの会社でDDDを活用して事業を成長させてきた中で、DDDのプラクティスの実践という面ではかなり大きな成果が得られました。 しかし、事業を成長させるという点において、DDDのプラクティスだけではうまくいかないこともあり、別のアプローチも同時に試行錯誤しています。 この発表では、うまく行ったプラクティスの内容と、カバーできなかった課題、そこに対する現在の取り組みについて紹介します。 ドメイン駆動設計 サンプルコード&FAQ https://little-hands.booth.pm/items/3363104 ドメイン駆動設計 モデリング/実装ガイド https://little-hands.booth.pm/items/1835632 ドキュメント内のブログ記事URL https://little-hands.hatenablog.com/entry/2020/12/22/ddd-in-first-3month
ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]
- 2. 自己紹介 2
- 3. ● 名前 ○ 松岡 幸一郎 (@little_hand_s) ● 所属 ○ 株式会社ログラス 経営管理領域でDDDを実践中 ● 運営コミュニティ ○ DDD community jp主催 ○ Agile Developers Community主催 ● 発信 ○ 「ドメイン駆動設計サンプルコード＆FAQ」 「ドメイン駆動設計モデリング/実装ガイド」執筆 ○ 質問箱 (DDD関連の匿名質問受付) ○ DDD関連の技術ブログ ○ Youtube DDD解説動画チャンネル ● その他活動 ○ 企業様へのDDD導入/設計サポートなど 自己紹介 3
- 4. ● ドメイン駆動設計モデリング/実装ガイド ● 2020年3月発売 ● DDDの目的やその用語について、 基礎から概念をしっかり解説します ○ モデリングからコーディングまでの流れ、 レイヤーごとの責務についてそれぞれ解説 執筆書籍紹介(1/2) 4
- 5. 執筆書籍紹介(2/2) ● ドメイン駆動設計サンプルコード &FAQ ● 2021年10月発売 ● DDDを実践する上でつまずきがちな問題を解消します ○ 「モデリング」「集約の実装」「テスト」について 詳細解説 ○ 質問箱に寄せられた約600の質問の中から、 頻出の質問について解説 ○ モデル図、サンプルコードを大量掲載 ● 前作では基礎概念の理解を 今作では実践する上での具体的な課題解決を目指します ● URLは動画概要にあります 5
- 8. ● ①ソフトウェアの機能性を高めること → 役に立つものを作る 「作ったけど使えない」を避ける ● ②ソフトウェアの保守性を高めること DDDの目的 8
- 9. ● ①ソフトウェアの機能性を高めること → 役に立つものを作る 「作ったけど使えない」を避ける ● ②ソフトウェアの保守性を高めること → 長期間開発しても機能拡張が容易でありつづける 「技術的負債でどんどん開発速度が低下する」を避ける DDDの目的 9
- 10. ● ①ソフトウェアの機能性を高めること → 役に立つものを作る 「作ったけど使えない」を避ける ● ②ソフトウェアの保守性を高めること → 長期間開発しても機能拡張が容易でありつづける 「技術的負債でどんどん開発速度が低下する」を避ける DDDでは 役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする ことを目指します DDDの目的 10
- 12. ● ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング ○ 「ドメインモデル」という抽象化した物にドメインの知識を反映することで、役に立つ ものになる可能性を高める ○ 開発初期だけではなく、各フェーズで得られた発見をこまめに フィードバックすることで改善頻度を上げる ● ②保守性向上のためのアプローチ DDDのアプローチ(1/2) 12
- 13. DDDのアプローチ(1/2) ● ①機能性向上へのアプローチ → ドメインエキスパートと共に行うドメインモデリング ○ 「ドメインモデル」という抽象化した物にドメインの知識を反映することで、役に立つ ものになる可能性を高める ○ 開発初期だけではなく、各フェーズで得られた発見をこまめに フィードバックすることで改善頻度を上げる ● ②保守性向上のためのアプローチ → 頻繁なモデルの更新に耐えられる実装パターン ○ モデルの形をそのままコードで表現することで、 頻繁なモデルの更新を反映しやすくる ○ 頻繁な更新に耐えられるように、 保守性の高いデザインパターン(エンティティ、リポジトリ等)を適用する 13
- 15. 15 ログラスにおける実践
- 17. ● 2020年1月 ○ DDDの外部講師として講義を行う(3回ほど) ● 2020年9月 ○ 入社 松岡とログラス 17
- 19. 松岡がログラスに入社した理由 ● DDDと相性がとてもよく、実践/実験の場としてとても適していた ● ニーズをしっかり押さえた市場選定がしっかりしており、伸びると思った ● 魅力的な人が多かった 19
- 20. DDDとの相性とは ● DDDは「ドメインが複雑な領域」に適用するのに向いている ● ログラスのドメインは「経営管理」 ○ 会計知識も必要で、業務自体を理解し、 解決策を考えるのが難しい ○ 適当に作っても最初は動くが、後からどんどん辛くなる →「機能性」「保守性」を高める余地が非常に大きかった 20
- 21. 実際のアプローチ ● TDD Boot Campの@t_wadaさんの基調講演観賞会を行った ● お手本となるコードを作成(メイン/テスト) ● レイヤーに跨るコーディング、テストの規約を整備 ● ドメインモデル図を作成し、それを元に開発 ● 地道なペアプロ、レビュー 詳しくはこちらの記事をご参照下さい 21
- 22. 割とすんなり行ったこと ● 松岡主導のモデル図作成 ● モデル図をもとにしたコーディング ○ 新規開発時、モデル図を何度もみながら開発ができ、役立った ● コーディング標準の普及 ○ お手本実装があることで、横展開しやすかった ● テスト実装 ○ テストがあるとめっちゃ楽じゃん、をとにかく感じてもらう ○ 「テスト！！」と常に言い続ける ○ 現在では「無いなんて考えられない」ぐらいには浸透 22
- 27. ● 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み ○ この辺りは、DDDのプラクティスである 「ドメインエキスパートと一緒にモデルを探求する」から、 さらにお客様の声を反映するためのアクションに踏み出す必要がある ● とにかく、お客様の解像度をあげる必要がある ○ プロダクトマネージャー、カスタマーサクセスと連携し、 ヒアリングと仮説検証を短期間で繰り返す ○ そして、そのサイクルを仕組み化 苦戦したこと、していること 27
- 29. ● 新機能 ○ EA(アーリーアクセス)リリース、GA(一般)リリースを分け、 EA対象企業を選定 ○ EA対象のお客様には、プロダクトマネージャー(PdM)と カスタマーサクセス(CS)と一緒にエンジニアがヒアリング ○ 機能の仮説を立てた段階でフィードバックをいただく ○ 4半期の目標(OKR)を「xx機能のリリース」ではなく「EA対象のXX社で新機能を運 用に乗せること」とする ● 既存機能 活用していただくための取り組み 29
- 30. 活用していただくための取り組み 30 ● 新機能 ○ EA(アーリーアクセス)リリース、GA(一般)リリースを分け、 EA対象企業を選定 ○ EA対象のお客様には、プロダクトマネージャー(PdM)と カスタマーサクセス(CS)と一緒にエンジニアがヒアリング ○ 機能の仮説を立てた段階でフィードバックをいただく ○ 4半期の目標(OKR)を「xx機能のリリース」ではなく「EA対象のXX社で新機能を運 用に乗せること」とする ● 既存機能 ○ CSからお客様の声を直接聞く機会をもうけ、そこからリファインメントしてスプリント に載せるまでをCRE(Customer Reliability Engineer)担当が実施 ○ 毎週「UX改善」枠チケット予算を確保し、安定した工数をつむ
- 31. まとめ ● DDDは機能性と保守性改善のために大きな効果を発揮する ● ただ、機能性はエンジニアだけ、社内だけに留まっていては上げきれない ● とにかくお客様の声を聞き、お客様の業務を理解すること そして仮説検証を小さく繰り返すことの仕組み化が大切！！ 31
- 32. 32