🏎️
「ドメイン駆動設計 - 実践企業が語るBefore/After - Vol.2」イベントレポート
公開
2025-04-03
更新
2025-04-03
文章量
約3299字
2025年3月27日、「ドメイン駆動設計（DDD）- 実践企業が語るBefore/After - Vol.2」と題したオンラインイベントが開催されました。前回1月に続き2回目となる本イベントは、実際にDDDを導入・運用している企業からリアルな事例をうかがいながら、複雑な業務ロジックへの取り組みやコアドメインの特定、そして組織に与えるインパクトなどを議論する場となりました。 今回はKINTOテクノロジーズ株式会社とキャディ株式会社の両社がそれぞれの事例を発表し、ファシリテーターとしてファインディが進行を担当。短いランチタイムにもかかわらず、多くの視聴者が参加し、チャット欄やQ&A欄を通じて盛り上がりを見せました。
本イベントについて
前回1月の開催に続く第2弾として行われた本イベントは、複雑なビジネスロジックを抱える開発現場でどのようにドメイン駆動設計を適用し、運用・改善を重ねてきたかを共有する場でした。各社のリアルなプロセスを紹介することで、参加者が自社の組織やアーキテクチャ設計に活かすヒントを得られるように企画されています。
ファシリテーターを務めたファインディ株式会社からは、DDD導入時における組織面の苦労や、コアドメインをどう見極めるのかなど、複数の質問を投げかけ、KINTOテクノロジーズとキャディの発表を掘り下げました。以下、それぞれの発表内容を要点とともにまとめます。
1. KINTOテクノロジーズ株式会社：決済基盤におけるドメイン駆動、実践運用の軌跡
導入背景・課題
KINTOテクノロジーズ社では、車のサブスク「KINTO ONE」など複数のモビリティ関連サービスを展開。新たに決済プラットフォームをゼロから構築するにあたり、ビジネスの拡大や複雑化が見込まれる中で「どう効率よく、かつ品質を落とさずに決済機能を実装するか」が大きな課題となりました。 さらに、エンジニアの所属やバックグラウンドが多様で「チームとしてDDDを学ぶ」必要性もあったそうです。
チーム体制と学び
チームは6名程度を軸に、ドメインエキスパート（決済業務の知識を持つ方）とエンジニアが協力するかたち。 DDDに詳しいメンバーもいればそうでないメンバーもおり、まずは書籍の輪読会を開いて共通認識を築いたり、モブでレビューを行って「実際のコードにDDDをどう落とし込むか」を習得していったとのこと。「モチベーションを保ちながら段階的に吸収したのが大きかった」との振り返りが印象的でした。
モデリング・アーキテクチャ上の工夫
イベントストーミングを参考に、最初はビッグピクチャーで概念を広く拾い上げ、後でプロセスモデリングやソフトウェアデザインへ落とし込む方法を導入
集約が大きくなりすぎたときは再分割するなど、実際の運用からのフィードバックでモデルをアップデート
プリミティブ型をそのまま使わず、Value Objectで型を明示的にしたい気持ちがあったが、忙しさなどの理由で一部妥協し「あとで直そう」という課題も
運用で見えてきた課題
「書くべきADRやドメインモデルを先にアップデートしないまま、開発を走らせてしまう」というアンチパターンが浮上。そこでPull Requestのテンプレートに「ドキュメント更新は完了済みか？」 などを盛り込み、チーム全体で声掛けをする仕組みを作ったそうです。また、観点が似通ってきた結果、テスト駆動の文化が根付きやすくなったとのこと。
品質への寄与
手応えとしては、テストカバレッジが安定して高く保たれ、インシデントも最小限に抑えられた点を挙げられました。また、DDDにおけるドメイン層の分離やテストのしやすさが、コード全体の複雑度を低減することにつながり、エンジニア同士のレビューも比較的スムーズだったそうです。
2. キャディ株式会社：製造業の会計システムをDDDで開発した話
プロジェクト概要と背景
キャディ株式会社は、「モノづくり産業のポテンシャルを解放する」というミッションのもと、製造業向けサービスを複数展開。今回取り上げられたのは会計システムの事例で、すでにサービス終了しているが、当時は受発注プラットフォームに紐づく「仕訳」や「在庫管理」を月次で正確に処理する必要があったとのこと。
要件はかなり流動的で、かつ開発期間が厳しい状況。にもかかわらずDDDの導入が決まった背景には「既存のプロダクトでもDDDが用いられ、共通の言語となっていた」点が大きいそうです。
DDDの取り入れ方
ドメインモデリングとデータモデリングを並行して進め、理解を深めやすくした
アグリゲートを大きめに取り、1回のバッチ=1アグリゲートとなる設計を選択。通常なら「大きいアグリゲートはアンチパターン」と言われるが、バッチシステムのためパフォーマンス上問題なく、逆に構造がシンプルになるメリットがあった
Value Objectを徹底し、単なるプリミティブではなく型で意味を持たせ、間違いを早期に検出できる形を採用
ドメインの整理と実装
福式簿記の表など会計独特の概念が多く、ドメインエキスパートとのすり合わせを丹念に行った
ラストで実装した部分はインターフェース（Trait）をドメイン層に置き、インフラ側でモック実装を生成。テストに活用しやすい
レポート機能を加え、経理担当者の不安を解消し、月次決算の妥当性を担保
プロジェクトを振り返って
長期にわたっても、ドメインモデルや用語集があれば新メンバーがスムーズにキャッチアップできたのが最大のメリット
バッチ処理でありながら「検証が必要なビジネスロジック」が多かった分、DDDの恩恵を感じやすかった
一方、「ドメインエキスパートへDDDの考え方を共有する時間が不十分だった」点が反省として挙げられた。早期に勉強会や対話を増やせばより良かったとのこと
全体を踏まえた感想：複雑さへ立ち向かい、継続的に進化するDDD
決済基盤や会計システムといった、業務知識の複雑度が高い領域でこそDDDが効果を発揮するという印象を強く受けたイベントでした。両社の事例に共通していたのは、以下のポイントです。
ドメインの理解をチームで深める学習体制 書籍の輪読会、モブレビュー、ドメインエキスパートとのこまめな対話――どれも地道ですが、結果として「モデルが腹落ちしたコード」を書ける組織文化を育んでいました。
ビジネスとアーキテクチャのすり合わせ 担当ドメインがある程度明確（会計・決済など）でも、実装過程で業務ロジックが変化しやすい。そこで、区切られたコンテキストやイベントストーミングの見直しを繰り返すことで、ビジネスの方向性とも足並みを揃え続けているのが印象的です。
テスト・品質面への好影響 大きめのアグリゲートやValue Objectを駆使しても、チームが意図を共有できていれば安定した運用が可能。カバレッジの確保や月次レポート生成で「安心感」を得て、事業拡大へリソースを振り向けられるとのこと。
イベント中には参加者から「組織でDDDを浸透させるには？」「指きたす言語をどう保守するか？」といった問いが多く寄せられました。こうした質問への回答からは、DDDは本だけでなく組織やコミュニケーションを変える試みでもあると実感します。
両社の実践例は、それぞれの課題を乗り越える中でチームが独自の設計や運用フローを作り上げており、「正解はなくても、共通認識を育てながら複雑性と戦っていく」DDDらしさが随所に見られました。今後、より柔軟なビジネス変化に対応するために「どうモデルを再分割するか」「エキスパートとの協業をどう深めるか」など、まだまだ先に挑戦が広がっているようです。
DDDに興味がある方や、導入を検討している方は、ぜひ今回の発表を参考にしつつ、まずはチーム内で小さく始めてみることをおすすめします。理論だけでなく運用面も含めて試行錯誤を重ねることが、ビジネスとシステムが噛み合った状態を育てるカギになるでしょう。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
