はじめに
DDD = Domain-Driven Design (ドメイン駆動設計)
DDDはよく「開発者目線」で語られることが多いですが、
DDDのエッセンスをプロダクト開発の中で実践していくことで、デザイナー・プロダクトオーナーを含むチーム全体での合意形成が圧倒的にやりやすくなりました。
この記事でお伝えしたいのはDDDの正しい知識・方法論ではなく、僕の体験に基づく DDDのここがイイです。
問題提起
たとえばこんな経験ありませんか？
- 話し合ってるのに、全員がちょっとずつ違うイメージを持ってる
- 「これどこの責務？」が曖昧で、実装がぐちゃっとなる
- 同じ用語なのに、職種ごとに意味が違う
- ミーティングで同じ議題への問いばかりしている
DDDは、こうしたチーム内の認識のズレを減らすための仕組みでもあります。
DDDは「認識を合わせる努力」を支えるフレームワーク
チームでDDDを理解しよう
開発者の間でDDDについて話されることは割とあると思います。
ですが、チーム全員でDDDを理解しようとする試みはしていますか？
しましょう。
一部の人たちが「イベントストーミングメッチャだいじ」「ドメイン境界はどこにあるんやア」「モデリング」「ユビキタス言語決めようぜ」と叫び続けても、なんのこっちゃ？と思われるだけです。
DDDを目的化しないためにもまずは理解し、適切にチームに普及していきましょう。
↑私的に腑に落ちる、納得感のある、わかりやすく内容の濃い素晴らしい記事と資料でした。DDDの理解を助けていただきありがとうございます。
話しても噛み合わないのは、言葉のズレから始まる
開発中によくあるのが、
同じ単語を使っているのに、チーム内で少しずつ意味が違うケースです。
「科目」「授業」「クラス」「講義」「レッスン」
人・チームによって定義がぜんぜん違う。
ここで重要なのが、ユビキタス言語（Ubiquitous Language） です。
ユビキタス言語は“最初に揃えるもの”ではない
ユビキタス言語は「最初に定義して固定するもの」ではありません。
むしろ、プロジェクトが進むたびに更新されていく“合意形成のプロセス” です。
- 会話の中で違和感が出たら言葉を見直す
- モデルの名前とドキュメントの表現を揃える
- 新しい概念が出てきたら、意味と使い方をチームで議論する
つまり、ユビキタス言語とは「認識を合わせ続けるための共通土台」。
資料やワークショップ、日々のコミュニケーションの中で育てていくものです。
誰かが仮に正しい定義を持っていたとしても共通認識として育てていかなければ意味がありません。
DDDは「正しい言葉・定義を断定すること」よりも、
「正しい言葉をみんなで見つけ続ける仕組み」をもつことが大事だなと思います。
自分たちの“境界線”をどう捉えるか
境界づけられたコンテクスト（Bounded Context）
もうひとつ大事なのが、
「どの文脈でこの言葉が通じるのか」を明確にすること。
「注文」という言葉を例にすると、
- 在庫チームでは「商品を確保した状態」
- 会計チームでは「支払い済みの状態」
と解釈が違うかもしれません。
この“文脈ごとの線引き”を明確にして、
それぞれのチームが自分の責務を理解できるようにするのが、
Bounded Context（境界づけられたコンテクスト） の考え方です。
Context Mapで「全体の地図」を描く
DDDでは、プロジェクト全体を「地図」として描きます。
どのBounded Contextがどこにあり、どう関係しているかを見える化する。
- どこが依存関係にあるのか
- どのチームがどの領域を担当しているのか
- どのモデルを翻訳・共有する必要があるのか
こうした構造が明確になると、
チーム間でのすれ違いがぐっと減ります。
「根拠のある議論」を支える仕組みとしてのDDD
DDDは単なるモデリング手法ではなく、
“根拠をもって話す” ことを強く助けてくれるツールです。
- 「なぜその設計なのか」をモデルで説明できる
- 「この仕様変更がどこに影響するのか」を言葉で共有できる
- 「どの文脈での話か」がすぐ明確になる
- 「用語や概念の理解」をチームの"あたりまえ"にできる (ユビキタス言語の整備)
つまり、議論を進めるための共通言語と地図を提供してくれる。
ここにDDDの価値があると感じます。
有効なDDDとは
DDDを目的にしてしまうと、
「とりあえずエンティティ作った」「リポジトリ定義した」みたいな状態になります。
でも本質はそこではなくて、
みんなが同じ理解のもとで意思決定できる状態を保つこと。
DDD = 合意形成の連続
根拠ある会話を支える“仕組み”として活かす
具体的にはこんな感じです：
- コードやドキュメントの命名を、ユビキタス言語で揃える
- 境界（コンテクスト）を意識して、責務を明確にする
- モデルや用語を定期的に見直し、合意を更新する
- チーム間の関係をContext Mapで共有する
これらを回していくことで、
チーム全体が「一枚の地図」を見ながら進めるようになります。
まとめ
DDDは「開発者のための設計理論」だけではなく、
チームが同じ方向を向くための道具です。
- 言葉を合わせる努力
- 境界を意識する習慣
- 議論のベースを明確にする文化
この3つが揃うだけで、チームの会話の質が驚くほど変わります。
モデルは、理解の結果。
DDDは、理解を“作る”ための仕組み。
DDDに登場する大切な概念や定義、手法についてはこの記事では触れきれていないのでぜひこの機会にご自身でもDDDを学んでみてください。
まずは下記をおすすめします。
もっと知りたい方は「エリック・エヴァンスのドメイン駆動設計」- 著: 牧野 祐子, Eric Evans
最後に
株式会社クロステックマネジメントでは、AIと教育の未来を一緒に創っていく仲間を募集しています。エンジニア志望の方はもちろん、新しい挑戦に意欲のある方のエントリーをお待ちしています。
参照
京都芸術大学のテックブログです。採用情報：hrmos.co/pages/xtm/jobs 芸大など5校を擁する瓜生山学園は、通信教育で国内最大手、国内で唯一notionと戦略パートナー契約を結ぶなどDX領域でも躍進、EdTech領域でAIプロダクトを開発する子会社もあり、実は多くのエンジニアがいます。
Discussion