はじめに
こんにちは、エンジニア2年目のはなまるです。
突然ですが、皆さんDDD（ドメイン駆動設計）ってどんなイメージを持っていますか？
- 「なんか意識高いやつらが使ってる」
- 「全員がDDDを熟知してないと、綺麗に始められないんでしょ？」
- 「既存の秘伝のタレ（レガシーコード）があるから、うちは無理」
ぶっちゃけ、私もそう思っていました。
しかし、オライリーの『ドメイン駆動設計をはじめよう』を読んだら、脳内がすっきりと晴れたのです。
なぜなら、この本は「理想のクリーンな世界」ではなく「泥臭い現実の世界」での戦い方を教えてくれる本だったからです。
この記事では、本書から学んだ「夢物語を捨てた現実的なDDDの心得」についてお話しします。
1. 「全員がDDDを熟知している世界線」は存在しない
まず、この本を読んで一番心が軽くなった（というか、現実をつきつけられた）のがここです。
よくある勘違いが、「よし、今日から我がチームはDDDを導入する！みんなでエヴァンス本（めちゃくちゃ分厚いDDDのバイブル）を読もう！」というやつ。
これ、高確率でチームが崩壊します。
モチベーションの温度差で風邪をひきます。
現実の壁：
- DDDに興味があるのは、言い出しっぺの自分だけ。
- 他のメンバーは「今の書き方でよくね？」「期日に間に合えば何でもいい」と思っている。
- そもそも、全員がDDDの難解な用語（エンティティ、集約など）を完璧に理解するまで待っていたら、サービスが終わった。
本書が教えてくれるのは、「全員をDDDマスターにする必要はない」ということです。
まずは、あなたがビジネスサイドの言葉を注意深く聞き、コードに落とし込むだけでいい。
周りには「なんか最近、仕様変更に強いコード書く人がいるな」と思わせるくらいからで十分なのです。
全員の足並みが揃うのを待つ必要はありません。
2. 新規開発ですら「綺麗な状態」では始められない
「じゃあ、新規のプロジェクトなら綺麗に始められるのでは？」
これも大きな罠です。
サービス立ち上げ初期なんて、ビジネスモデル自体が毎日変わります。
ドメイン（ビジネスの核心）が何なのか、社長すら分かっていないフェーズです。
そんな中で、完璧な「境界づけられたコンテキスト」なんて引けるわけがありません。
学んだこと：
最初はみんな「ドメイン」のことが分かっていない。
だから、最初から綺麗なモジュール分けなんて無理。
最初はあえて大きめの境界（あるいはモノリス）で始めて、ビジネスの輪郭が見えてきてから境界を切り出すのが正解。
「初期から完璧に設計する」という完璧主義を捨てることこそが、実践的なDDDの第一歩です。
まとめ：完璧主義を捨てて、部分最適から始めよう
『ドメイン駆動設計をはじめよう』を読んで救われたのは、「すべてをDDDでガチガチに作らなくていい。
現実を見ろ、泥にまみれながら境界線を引け」と、徹底的に実利主義なスタンスをとってくれている点です。
- 全員が知らなくてもいい。
- 最初から綺麗じゃなくていい。
「楽をするために、複雑なところを見極めて、そこにだけ本気を出す」
これが、この本からの発見でした。
もし「DDDって難しそう…完璧にやらないと意味ないんでしょ？」と足がすくんでいる人がいたら、この本はめちゃくちゃ親切に「泥臭い現実の戦い方」を教えてくれるので、超おすすめです！
次回予告
今回はマインド編として「完璧な世界なんてない」というお話をしました。
来週もDDDに関する記事を投稿予定なので、ぜひご覧ください！