ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]

2022.1.17
松岡幸一郎 (@little_hand_s)
1
ドメイン駆動設計のプラクティスで
カバーできること、できないこと

● 名前
○ 松岡幸一郎 (@little_hand_s)
● 所属
○ 株式会社ログラス
経営管理領域でDDDを実践中
● 運営コミュニティ
○ DDD community jp主催
○ Agile Developers Community主催
● 発信
○ 「ドメイン駆動設計サンプルコード＆FAQ」
「ドメイン駆動設計モデリング/実装ガイド」執筆
○ 質問箱 (DDD関連の匿名質問受付)
○ DDD関連の技術ブログ
○ Youtube DDD解説動画チャンネル
● その他活動
○ 企業様へのDDD導入/設計サポートなど
自己紹介
3

● ドメイン駆動設計モデリング/実装ガイド
● 2020年3月発売
● DDDの目的やその用語について、
基礎から概念をしっかり解説します
○ モデリングからコーディングまでの流れ、
レイヤーごとの責務についてそれぞれ解説
執筆書籍紹介(1/2)
4

執筆書籍紹介(2/2)
● ドメイン駆動設計サンプルコード
&FAQ
● 2021年10月発売
● DDDを実践する上でつまずきがちな問題を解消します
○ 「モデリング」「集約の実装」「テスト」について
詳細解説
○ 質問箱に寄せられた約600の質問の中から、
頻出の質問について解説
○ モデル図、サンプルコードを大量掲載
● 前作では基礎概念の理解を
今作では実践する上での具体的な課題解決を目指します
● URLは動画概要にあります
5

6
DDDの目的
(認識合わせ)

● ①ソフトウェアの機能性を高めること
● ②ソフトウェアの保守性を高めること
DDDの目的
7

→ 役に立つものを作る
　「作ったけど使えない」を避ける
DDDの目的
8

→ 長期間開発しても機能拡張が容易でありつづける
　「技術的負債でどんどん開発速度が低下する」を避ける
DDDの目的
9

→ 長期間開発しても機能拡張が容易でありつづける
　「技術的負債でどんどん開発速度が低下する」を避ける
DDDでは
役に立つソフトウェアを、長期間保守性を下げずに作り続けられるようにする
ことを目指します
DDDの目的
10

● ①機能性向上へのアプローチ
● ②保守性向上のためのアプローチ
DDDのアプローチ(1/2)
11

→ ドメインエキスパートと共に行うドメインモデリング
○ 「ドメインモデル」という抽象化した物にドメインの知識を反映することで、役に立つ
ものになる可能性を高める
○ 開発初期だけではなく、各フェーズで得られた発見をこまめに
フィードバックすることで改善頻度を上げる
12

→ ドメインエキスパートと共に行うドメインモデリング
○ 「ドメインモデル」という抽象化した物にドメインの知識を反映することで、役に立つ
ものになる可能性を高める
○ 開発初期だけではなく、各フェーズで得られた発見をこまめに
フィードバックすることで改善頻度を上げる
→ 頻繁なモデルの更新に耐えられる実装パターン
○ モデルの形をそのままコードで表現することで、
頻繁なモデルの更新を反映しやすくる
○ 頻繁な更新に耐えられるように、
保守性の高いデザインパターン(エンティティ、リポジトリ等)を適用する
13

よく「DDDならモデリングしないと意味ないよ」と言われがちだが…
● 2つのアプローチは、目的さえ明確であれば個別でも十分に価値を発揮する
● ただし、2つのアプローチは「ドメインモデル」で繋がっており、
一緒に適用するとより大きな価値を発揮する
14

15
ログラスにおける実践

● 2020年1月
○ DDDの外部講師として講義を行う(3回ほど)
松岡とログラス
16

● 2020年1月
○ DDDの外部講師として講義を行う(3回ほど)
● 2020年9月
○ 入社
松岡とログラス
17

いらすとやはどんなイラストでもあるな〜
18

松岡がログラスに入社した理由
● DDDと相性がとてもよく、実践/実験の場としてとても適していた
● ニーズをしっかり押さえた市場選定がしっかりしており、伸びると思った
● 魅力的な人が多かった
19

DDDとの相性とは
● DDDは「ドメインが複雑な領域」に適用するのに向いている
● ログラスのドメインは「経営管理」
○ 会計知識も必要で、業務自体を理解し、
解決策を考えるのが難しい
○ 適当に作っても最初は動くが、後からどんどん辛くなる
→「機能性」「保守性」を高める余地が非常に大きかった
20

実際のアプローチ
● TDD Boot Campの@t_wadaさんの基調講演観賞会を行った
● お手本となるコードを作成(メイン/テスト)
● レイヤーに跨るコーディング、テストの規約を整備
● ドメインモデル図を作成し、それを元に開発
● 地道なペアプロ、レビュー
詳しくはこちらの記事をご参照下さい
21

割とすんなり行ったこと
● 松岡主導のモデル図作成
● モデル図をもとにしたコーディング
○ 新規開発時、モデル図を何度もみながら開発ができ、役立った
● コーディング標準の普及
○ お手本実装があることで、横展開しやすかった
● テスト実装
○ テストがあるとめっちゃ楽じゃん、をとにかく感じてもらう
○ 「テスト！！」と常に言い続ける
○ 現在では「無いなんて考えられない」ぐらいには浸透
22

時間をかけて少しずつ進んだこと/進んでいること
● モデリング必要性の浸透、松岡以外による推進
○ 「モデリング役に立つじゃん」を徐々に感じてもらいながら、
少しずつモデリング作業の必要性が広まっていった
23

● 単純にテストコードがめっちゃ増えた
● プルリクで新規でテストの修正が無いものはほぼ無い
変化が実感できた時(テスト)
24
松岡
入社

変化が実感できた時(モデリング)
● 「モデリングしたいので一緒にモブ作業してくれませんか」
と言われる頻度が増えた時
● 新規プロジェクトの開発チケットに「ドメインモデリング」が
当然のように作成された時
25

● 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み
○ この辺りは、DDDのプラクティスである
「ドメインエキスパートと一緒にモデルを探求する」から、
さらにお客様の声を反映するためのアクションに踏み出す必要がある
苦戦したこと、していること
26

● 「何を作るか」から「どうすれば活用してもらえるか」への踏み込み
○ この辺りは、DDDのプラクティスである
「ドメインエキスパートと一緒にモデルを探求する」から、
さらにお客様の声を反映するためのアクションに踏み出す必要がある
● とにかく、お客様の解像度をあげる必要がある
○ プロダクトマネージャー、カスタマーサクセスと連携し、
ヒアリングと仮説検証を短期間で繰り返す
○ そして、そのサイクルを仕組み化
苦戦したこと、していること
27

● 新機能
● 既存機能
活用していただくための取り組み
28

● 新機能
○ EA(アーリーアクセス)リリース、GA(一般)リリースを分け、
EA対象企業を選定
○ EA対象のお客様には、プロダクトマネージャー(PdM)と
カスタマーサクセス(CS)と一緒にエンジニアがヒアリング
○ 機能の仮説を立てた段階でフィードバックをいただく
○ 4半期の目標(OKR)を「xx機能のリリース」ではなく「EA対象のXX社で新機能を運
用に乗せること」とする
● 既存機能
29

30
● 新機能
○ EA(アーリーアクセス)リリース、GA(一般)リリースを分け、
EA対象企業を選定
○ EA対象のお客様には、プロダクトマネージャー(PdM)と
カスタマーサクセス(CS)と一緒にエンジニアがヒアリング
○ 機能の仮説を立てた段階でフィードバックをいただく
○ 4半期の目標(OKR)を「xx機能のリリース」ではなく「EA対象のXX社で新機能を運
用に乗せること」とする
● 既存機能
○ CSからお客様の声を直接聞く機会をもうけ、そこからリファインメントしてスプリント
に載せるまでをCRE(Customer Reliability Engineer)担当が実施
○ 毎週「UX改善」枠チケット予算を確保し、安定した工数をつむ

まとめ
● DDDは機能性と保守性改善のために大きな効果を発揮する
● ただ、機能性はエンジニアだけ、社内だけに留まっていては上げきれない
● とにかくお客様の声を聞き、お客様の業務を理解すること
そして仮説検証を小さく繰り返すことの仕組み化が大切！！
31

ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]

Recommended

More Related Content

What's hot (20)

Similar to ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD] (20)

Recently uploaded (9)

ドメイン駆動設計のプラクティスでカバーできること、できないこと[DDD]