🏎️
【イベントレポート】ドメイン駆動設計 - 実践企業が語るBefore/After -
公開
2025-04-13
更新
2025-04-13
文章量
約3477字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
サービスが複雑化する中、組織を変革するほどの効果をもたらす可能性がある「ドメイン駆動設計（DDD）」。本イベントでは、2社の実践事例を通して、なぜDDDを導入しようと考えたのか、どのような壁を乗り越えて実装を進めたのか、そして導入後にどんな改善があったのかについて語られました。以下に、その内容をまとめます。
はじめに
今回のイベントには、LINEヤフー株式会社の山口さん・塩川さん、パーソルキャリア株式会社の池田さんが登壇しました。いずれの事例も「既存システムの大規模なリプレース」や「肥大化したコードベース」「不透明な仕様」といった問題に直面し、それを打開するためにドメイン駆動設計を取り入れています。
それぞれの発表では、単にDDDの概念に留まらず、実際のソースコード構造やアーキテクチャの変遷、さらに新機能や企画サイドとの連携といった視点も示されました。全体としては「DDDによって何がどこまで変わるのか」を実感できるセッションになりました。
LINEヤフー：ドメイン駆動設計で支えるショッピングクーポン
背景：成長を支えるクーポンシステム
ヤフーショッピングのクーポン機能は、ストア発行クーポンやターゲティング対応クーポンなど、多様なバリエーションを抱えつつ事業を加速してきました。しかし、ビジネスの要求に合わせてシステムが増改築を繰り返すなかで、
膨大なIF文によるロジックの複雑化
業務用語とコード用語の乖離
新人や他部署が触りにくいブラックボックス化
といった課題が蓄積していました。
DDD採用と実践
そこで約5年前、クーポンシステムをゼロベースで再構築する際に、ドメインモデルを明確にすることを意図的に採り入れたとのこと。特に注力したのは以下のポイントです。
ドメインエキスパートの密な連携
クーポン機能を深く理解する山口さんが、開発者とペアプロや対話を繰り返すことで、業務ロジックとモデルのつながりを明確化。
レイヤードアーキテクチャ
ドメイン層にビジネスロジックを集約し、インフラ層やプレゼンテーション層の関心事を切り離す。
データとロジックの一体化
クーポンやバスケットなどの概念ごとにエンティティを用意し、不変性や「閉じた操作（メソッドチェーン）」で複雑な分岐を整理。副作用を排除してテストしやすい設計を心がけた。
計算・組み合わせ探索の最適化
同じ「商品行動指定クーポン」でも、クラスごとにポリモーフィズムでロジックを差し替えるなど、スイッチ文を極力廃止。
Ater：複雑性に耐える強さ
実際にリリース後は「クーポン処理の分岐パターンが増えても、開発スピードが落ちず、誰でも安心して中核コードを変更できる」ようになったそうです。仕様の複雑性とシステムの複雑性がイコールになるため、「重い機能ほど行動も重くなる」といった無駄が減り、DDDの威力を実感できたとのこと。
パーソルキャリア：dodaダイレクトのリビルド実践
なぜリビルドに至ったのか
パーソルキャリアの池田さんからは、同社が運営する「dodaダイレクト」の再構築事例が紹介されました。dodaダイレクトは企業から候補者に直接スカウトするサービスで、市場成長に合わせて拡張し続けた結果、
コードの肥大化と保守性の低下
データベース共有による「分散モノリス」化
ドキュメント消失と仕様不明
が顕在化し、部分的なリファクタリングでは解決が難しい状態となっていました。そこで、現行システムをビッグバンでリビルドする方針を採択。ドメイン駆動設計を軸に、アーキテクチャを根本から組み直す道を選んだとのこと。
仕様の掘り起こしとアーキテクチャ設計
コンテキストマップの作成
まずは既存コードとヒアリングで大まかな機能領域を把握。そのうえで領域ごとにモデリングを行い、仕様の粒度を確定。
CQRS＋イベントソーシング
複雑な参照リクエストと更新ロジックを切り離し、「読み取りモデル」「書き込みモデル」を分割。
各ドメインサービスの連携はイベント駆動にすることで、ゆるやかな結合を保ちつつ整合性を保てる。
GraphQLによるBFF不要化
サービスごとにサブグラフを公開し、フェデレーションでスーパーグラフを構築。フロントエンドは1つのエンドポイントに問い合わせるだけで済むため、開発効率も向上。
進捗と学び
リファクタリングだけでは収まらないほど複雑な負債を抱えていたため、ビッグバンを選択。ただしデータの移行は段階的に行い、ストラングラーパターンに近い運用でリスクを軽減している。
モデラーの育成
チーム内でペアモデリングを繰り返し、モデルの整合性を保つ。熟達したモデラーが1人に偏らないよう配慮。
既存データとの乖離
不明瞭な仕様やテーブル構造が多く、ドメインモデルとの対応をどうマッピングするかが課題。場合によってはドメインを少し妥協してデータに合わせるケースも検討中。
Q&Aハイライト
イベント後半では、参加者から多数の質問が寄せられました。特に多かったテーマは以下の通りです。
モデラー育成の具体策は？
2社とも「ペアモデリング」と「ドメインエキスパートとの密なやり取り」を強調。企画やマーケ、営業とも対話しながら、ホワイトボードでモデリングする習慣を根付かせる事例が多い。
DDD導入時の既存データベース共有どう解消する？
LINEヤフーの場合、独自テーブルでドメインの複雑性を吸収しつつ、既存DBを最小限参照。パーソルキャリアも段階的フェーズで移行し、最終的に独自DBへ移す形に。
大規模組織でのドメイン知識獲得法
山口さんいわく、「社内で週次に『問い合わせ共有会』を開いて、ロジックや用語の意味を共有する」。池田さんは「ワークショップでモデリング手法を共有し、業務側との用語をスムーズにひも付け」。
全体を踏まえた感想
大規模システムのアーキテクチャ刷新という難易度が高い挑戦に対し、両社ともドメイン駆動設計を軸に据えることで、仕様やビジネス要件の膨大な複雑性を「整理しやすい単位」に落とし込みながら前進しているのが印象的でした。
LINEヤフーのショッピングクーポン事例では、ドメインモデルが「業務知識の使用書」 と呼べるほど、データとロジックを一体化している点が顕著。組み合わせ割引などの複雑なロジックでも、新入社員が短時間で読み解けるほど可読性を高めるメリットを得ています。
パーソルキャリアのdodaダイレクト事例では、リビルドしなければ解決できないレベルの技術負債を逆にチャンスとして、CQRS＋イベントソーシング＋GraphQLを掛け合わせた最新アーキテクチャを実装中。コード解析とコンテキストマップを往復することで、「分からない仕様」を順次埋めていくプロセスが印象深いです。
「DDDは魔法ではない」という声もよく聞きますが、実際にシステム全体を見直す中で、モデリングの丁寧さやレイヤーごとの関心の分離がどれだけ組織を楽にするかが改めて伝わってきました。今後、さらに複雑化が進むサービスを支えるためにも、業務知識の明確化と、それを反映したコード設計が重要であると感じられる内容でした。
イベント後の質疑応答でも多数の質問が飛び交い、特に「モデラー育成」や「既存DBとの乖離解消」などに強い関心が寄せられたのが印象的でした。両社とも、リアルな実践で得た知見から「ペアモデリング」「分析モデルとドメインモデルのすり合わせ」「ドメインエキスパートとの連携」などを繰り返す大切さを強調していました。
あとがき
DDDのメリットを最大限発揮するには、ドメイン理解・アーキテクチャ・チーム連携など、あらゆる面で地道な取り組みが必要です。その結果として、システムが複雑に進化しても“仕様の複雑さ＝システムの複雑さ”となり、過度な混乱を抑えながら新しいサービスを展開し続ける基盤を得られる、という事例が今回の2社に共通していました。
各登壇者が口を揃えたように、ドメインモデリングの精度を高めるためには、人の育成と組織での共通言語の定義が欠かせないとのこと。どうしてもスキルや知識が特定の人に集中してしまいがちですが、ペアプロやワークショップ、ロジック共有会などを積極的に活用しながら、チーム全体でDDDを支える体制を作ることが重要といえそうです。
サービスの拡張やリプレース、チーム拡大にともなって「ドメイン駆動設計をもう一度見直してみよう」と考える方々に、今回の事例が一助になれば幸いです。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
