この記事について
- DDDを個人的に勉強し、自分で納得がいくように理解できたのでその知見を紹介しようと思います
- あくまでも個人的な理解なので、参考程度に留めてください
- なるべく難しい言葉を使わないようにし、自分の言葉でまとめるようにしました
DDDとは結局何なのか
- かなり広い概念を表していると思いました。大きく3つの考えが合わさっていると思います。
- 何はともあれドメインが中心の世界。ドメインとはそのソフトウェアで解決したい問題、活動の領域。このドメインを中心にプロダクトを作ろうという話。
- 開発者は1人でプロジェクト立ち上げから、ソフトウェア開発、マーケティングなどの業務をこなすことはまずないです。そのときに、各部署やチーム内でプログラム言語などの専門的用語を知っている人は少ないです。また、逆に開発者はビジネス用語やマーケティング用語に疎いです。これでは円滑なコミュニケーションが測れないため、ユビキタス言語やコンテキストを導入します。
- 開発していく中で、プログラマーが1人でないとしたら、引継ぎや役割分担などを円滑に行える必要があります。また、テストや修正が入ることもしばしばあります。そのためにアーキテクチャを導入します。
この3つの考えを統合していくのがDDDの思想なのだと思います。
DDDの勘違いしやすいポイント
- DDDとは何か具体的なコードの書き方を示したものではなく、答えはない。つまりDDDとは単なる概念、思想である
- 一発でユーザーのニーズや用件を満たせるコードがかければ良いに越したことはないが、DDDはそのようなものを目指してはおらず、トライアンドエラーやアジャイル的に開発していく
発案者の言葉も確認
- 発案者はEric Evansというお方だそうです。本人自身も定義は難しいと前置きを置いた上で以下のように発言しています。
What is Domain Driven Design?
1. Focus on the core complexity and opportunity in the domain
2. Explore models in a collaboration of domain experts and software experts
3. Write software that expresses those models explicitly
4. Speak ubiquitous language within a bounded context
- こちらには分かりやすい意訳がありました。
-
あえて私なりの言葉で訳すと、
- アプリケーションの対象(ドメイン)の複雑さと機会に焦点を当てる
- 開発者とドメインについての専門家が共に関わり、最良なモデルを探索する
- 開発者はこのモデルを明確に表現する
- 決められた範囲(コンテキスト)の中で共通理解のある言語(ユビキタス言語)を使って話す
個人的には初めて文章を読んだときにドメインという言葉が、URLのドメインを表しているのかと思ったのですが、そういうわけではなくて、現実世界のマーケティングの対象となる範囲を示しているのかもしれないと感じました。さらに、どの場面でもとあるユビキタス言語で話すのかと思っていましたが、チームごとにとか、部署ごとに違うユビキタス言語を使って良いんだと思いました
開発者の本領が発揮されるのは3の部分で、ここにオニオンアーキテクチャやクリーンアーキテクチャが関わってくるようです。この3だけを取り上げると、軽量DDD(戦術的DDD)と言うそうです。Qiitaにはこの軽量DDDの記事が多いと思います(技術的な要素がここに詰まっているので仕方ないとは思います)
終わり
- 自分なりの言葉でDDDをまとめてみました。軽量DDDでよく出てくるアーキテクチャやエンティティ、値オブジェクトについても時間があれば書いてみようと思います(書き次第ここに追記します。)ただ上にあげた文献がとても分かり易かったので、そちらをみた方が良いかもしれません
- 誰かの理解の助けとなれば幸いです