最近、自分たちのチームでドメイン駆動設計（DDD）をアプリケーション開発に導入した。
その経験から得た気づきや効果について、今回はまとめてみる。
DDD導入の前提として重要なこと
DDDは「知識（ナレッジ）をコードに集約する」設計思想。
その結果として、非常に見通しの良い、メンテナンス性の高いコードを書くことが可能になる。
しかし、チームにDDDを導入・定着させるには一つ大きなポイントがある。
それは、旗振り役の存在。
しかも、この旗振り役は、DDDにある程度深く精通している必要がある。
というのも、DDDは初学者にとっての学習コストが高く、概念が理解できずにすぐ行き詰まる。
正直、自分も独学でやるには大変で、一人で幾度となく使って、人に教えられるレベルになるまで、2年は掛かった。。
実際、自分の感覚では「最低でも3回はDDDを使って構築してみて人にも教えられる」と感じている。
そのくらい繰り返して初めて、全体像と勘所が掴めるようになるからだ。
DDDを導入して感じた効果
まず、導入して良かったと感じたのは、コードの見通しが非常に良くなったことだ。
特に、ロジックとインフラ技術的な関心ごとを明確に分離できたことが大きかった。
DDDではドメイン層、アプリケーション層、インフラ層などに責務を分けるアプローチを取る。
これによって、チームの中でも若手メンバーが「どう書けばいいのか」を理解しやすくなり、
自然と全体の設計レベルが上がっていった。
また途中参画のメンバーであっても、「ロジックがどこに書かれているか」というのが明確なため、これまでのように、いちいち散逸したドメインを探す手間や、「何がまだかかれてないか」ということを知るのに要する時間を減らすことができた。
これは、もともとある程度ベテランエンジニアであれば自然と身についている考え方かもしれない。
ただ、それを仕組みとしてチーム全体に浸透させられるのが、DDDの強みだと感じている。
副次的な効果：レビューの観点が明確になった
もう一つ意外だったメリットとして、コードレビューの観点が明確になったことがある。
今回の開発ではテストとDDDを組み合わせて進めた。
テストコードで挙動を担保しているため、レビュー担当者は「動くかどうか」を確認する必要が下がった。
代わりに、
- ドメイン層にロジックがきちんと集約されているか
- 責務ごとに適切に分離されているか
といった、設計と構造そのものにフォーカスしてレビューできる。
これは、オニオンアーキテクチャのようなレイヤードな構成を取ったことも大きく、
ドメイン、アプリケーション、サービス、インフラ、コントローラーといった各レイヤーの役割が
はっきりしていたからこそ実現できたものだ。
チーム開発における効果
今回のプロジェクトは、5人ほどの開発チーム規模のものだった。
要件自体も非常に複雑かつ制作中も要件が変わっていくような性格のものだったのだが、DDDによって
- どこにどの要件が書かれているのか
- 仕様変更時にどこを直せばよいのか
が非常に明確になった。
チーム全体としてコードの見通しが良く、設計方針も共有できたことで、
効率的かつ品質の高い開発ができたと実感している。
また正直若手エンジニアの能力を上げる効果もあった。
自然と責務を意識したコードを書けるようになり、一気に成長し、それ以降のプロジェクトでも設計に迷いづらくなったように感じている。
「CatクラスとかDogクラスが何の意味があるの？」と思っていた段階から、クラスの恩恵と意味も感じてもらうことができた。
DDDは最初こそハードルが高く感じられるものの、
きちんとチームに浸透すれば確実に開発体験と成果物の質を向上させてくれる設計アプローチだ。
導入を検討されている方の参考になれば幸いだ。
導入のハードル
学習コストの高さ
ただし、実際にDDDを書こうとすると、かなり詰まることが多い。
というのも、DDDは**「どう書くか」を直接的には教えてくれない**からだ。
一つひとつの哲学を理解し、概念を咀嚼した上で、自分なりの設計の結論を導き出す必要がある。
しかもその結論は、プロジェクトの規模や要件によっても異なってくる。
上の人間の理解
ドメイン駆動を実践的に使えるようになるまでも時間がかかるが、上長が理解ある人間ではないと難しい。
今回は元請けのPMの方が技術畑の出身で、「新人の教育になるなら」と導入を了承してくれた。また新人の皆さんも「コードの理解が進んだ」「初めてクラスが存在する意義がわかった」と感謝された。
自分が見てても彼らはそのプロジェクトを通して大変成長した。
ただ、その元請け会社の社長にはやはり説明が難しく、自分の言葉足らずで「DDDやって気持ちよくなった、って話？」と言われてしまった。。今でもちゃんと説明できなかったのが悔しい。。
おまけ。どうやってDDDを身につけるか
DDDを学ぶためのおすすめリソース
もしこの記事を読んでDDDに興味を持たれた方がいれば、ぜひ以下のリソースも参考にしてみてほしい。
松岡さんのYouTubeと書籍
まずは、松岡幸一郎さんが配信しているDDDに関するYouTube動画を見ることをおすすめする。
概念の紹介から実践的なTipsまで丁寧に解説されており、導入のとっかかりとして非常に有益だ。
興味が深まった場合は、彼が出している薄い本にも目を通してみてほしい。
より踏み込んだ実践内容や設計思想に触れることができる。
Youtubeで公演も公開されてるのでご覧になると良い。すごいイケメンだ。
成瀬さんの動画・書籍も必読
次に紹介したいのが成瀬允宣さん（お名前が難しい）だ。
彼もDDDの主要なエヴァンジェリストの一人であり、 YouTubeでの解説動画や、自身が執筆した技術書も非常にまとまっている。
まずは動画で概要を掴み、その後に書籍で体系的に学ぶという流れがおすすめだ。
（旧Twitterでメッセージ送らせて頂いたことがあるが、大変懐の深い温かい方であった。）
DDDの損益分岐点
まずDDDは長期的な視点に立てば低コストである。
銀の弾丸では無いので、盲滅法に導入すればいいとは思わない。
自分の経験も交えていうなら、以下のような場合が判断基準だと思っている
- 中長期的に作られたシステムをメンテナンス、保守、拡張する見込みがある
システムを中長期的にメンテナンス・保守しなければならない時に力を発揮する。
ただし、構造を全く理解しない手の入れ方をしてしまうと、秩序が乱れて旨みが失われるどころか、一気に負債化してしまう。
基本的には手を入れたメンバーが保守をするか、ドキュメントに残す、ドメイン依存構造を強制するようなLinterでエラーを出すようにする、などの一定の工夫は必要だと思う。
（ただしその努力は、どんなシステムでも変わらないと思う）
- 操作が2つ以上の入り口から行われる
例えば権限や部門の違うユーザーや、管理者が同じようなオブジェクト操作する時。
共通のオブジェクトを操作するが権限などで出していいもの、出してはいけないもの、などが存在してる時。
例えば商品オブジェクトを一般消費者、特別クーポン適用者、管理者が閲覧したり操作したりする、請求情報を経理、営業、経営者がそれぞれ閲覧したり操作したりする、などである。
そのような時にドメイン駆動の本領が発揮される。
コードの見通しの良さに多くのエンジニアがアーキテクトに惚れちゃうと思う。
まとめ
今回、実際のプロジェクトでDDDを導入した経験を振り返ってみた。
自分も最初は学習コストの高さに悩まされ、チームのレールになれるコードを書けるようになるまで時間がかかった。
しかし、粘り強く推進した結果、確実に開発の質が向上したと実感している。
特に印象的だったのは、DDDが単なる設計手法を超えて、チームの成長を促進するツールになったことだ。若手エンジニアが責務分離の考え方を自然と身につけ、中堅エンジニアはより高度な設計判断ができるようになった。複雑な要件変更にも柔軟に対応でき、コードレビューの質も向上した。
もちろん、DDDは万能薬ではない。短期的なプロトタイプや、シンプルなCRUDアプリケーションには過剰な場合もある。しかし、中長期的な視点で見れば、投資に見合うリターンが得られる設計アプローチだと確信している。
AIの登場で今後の設計思想は変わってくるかもしれないが、人類が自、より良い設計、というものを考えた求め続けた時の一つの答えであったろうと思う。
Discussion