DDD連載記事
- なぜDDD初心者はググリ出してすぐに心がくじけてしまうのか
- ドメイン駆動設計の定義についてEric Evansはなんと言っているのか
- モデルでドメイン知識を表現するとは何か
- ドメイン駆動設計で実装を始めるのに一番とっつきやすいアーキテクチャは何か
- ドメイン駆動 + オニオンアーキテクチャ概略
ドメイン駆動設計について、「どうやって実装するのさ？」の前に、まずは定義について認識合わせをしたいと思います。
背景
「ドメイン駆動設計とは何か？」
ドメイン駆動設計について興味を持った時に、一番最初に疑問に思うのがこれですね。
ところが、ググって見ると結構いろんなサイトでいろいろな書きぶりをしているんですよね・・・。
「顧客と開発者が業務を戦略的に理解し、共通の言葉を使いながらシステムを発展させる手法」
ドメイン駆動設計のメリットと始め方(Codezine記事)
「厳しい現実の中で、ソフトウェア設計を習得しようと奮闘してきた技術者の物語。不完全な状況の中で、抽象的な設計原則を、現実のソフトウェアに適用するための助言 日本語版への序文by エリック・エヴァンス」
ドメイン駆動 基本を理解する(ギルドワークス増田さんのスライド)
「ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする」
Wikipedia ドメイン駆動
うーん、かぶるところもあるし、違うところもあるし、結局何が正しいのかわからないですね。
いろいろな方の解釈が入っているので、どれが間違っているということはないと思いますが、入り口としては混乱してしまいます。
さらに、Eric EvansのDDD本、実践ドメイン駆動(IDDD)を読んでも、いろいろとDDDすべき理由など書いてあるんですが「DDDとは？」と言い切っているところが意外とないんですよね。
これがまずDDD入門の最初の障壁かと思います。
そこで、***「一次ソースにあたれ」***の発想で、Eric EvansがWeb上で公式に発信している情報を探してみましょう。まずはそれを共通認識にしようではありませんか。
Domain Langugaeの公式サイト
ありました。DDDの総本山とも言うべきサイトが。「About Us」にもEric Evansの名前が載っています。ここに書いてあることはきっと正しいに違いありませんね。
結構講座とかe-learningの話が中心のサイトなのですが、良いものがありました。
こちらのリンクにあるPDFが、Eric EvansのDDD本で定義されているパターンの簡単なサマリで、2015年に書かれたものだそうです。
また、
Videos from DDD Europe 2016の"where DDD is now"のリンクにも本人が「What is DDD?」などについて1時間話しているビデオがあります。
これを参考にしていきましょう。
ドメイン駆動の定義
DDD ReferenceとVideos from DDD Europe 2016では、実は定義の文言が少しだけ違うので、1年新しいビデオの方の定義を見てみましょう。
DDD の明確な定義は難しいと前置きした上で、DDD とは以下4つの原則からなると説明しています。
What is Domain Driven Design?
- Focus on the core complexity and opportunity in the domain
- Explore models in a collaboration of domain experts and software experts
- Write software that expresses those models explicitly
- Speak ubiquitous language within a bounded context
意訳すると以下のようになると思います。
ドメイン駆動とは？
- ドメイン(＊1)の中核となる複雑さと機会に焦点を当てる
- ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
- 明示的にそれらのモデルを表現するソフトウェアを書く
- 境界付けられたコンテキスト(＊2)の中のユビキタス言語(＊3)で話す
(＊末尾に用語の定義を乗せたので参照してください。)
以下、ビデオの説明を要約します。
ドメインの中核となる複雑さと機会に焦点を当てる
技術的な問題ではなく、ドメインの"価値のある、複雑な部分"にフォーカスするべきである。
ドメイン専門家とソフトウェア専門家のコラボレーションでモデルを探求する
モデルは一度定義して終わりではない。
継続的に行われ続けるものであるから、モデルの「探求(Explore)」という言葉を使っている。モデルの探求は、ソフトウェア開発者とドメインエキスパートが協調して行うものである。
ソフトウェア開発者はドメインエキスパートに「あなたはビジネスに詳しいのだからモデルを提示してください。私たちはソフトウェアについて責任を持ちます。」と言ってしまいがちである。しかし、モデルの探求を一緒に行うことこそがソフトウェア開発を成功させるために必要なことである。
明示的にそれらのモデルを表現するソフトウェアを書く
ソフトウェアはモデルを表現する必要がある。
ドメインエキスパートと素晴らしい議論をして、様々なコンセプト、ガイド、図、を作ったとしても、最終的には明示的にソフトウェアに表現されなければならない。
境界付けられたコンテキストの中のユビキタス言語で話す
言語の意味を定義づける境界を定義し、その中ではすべての人(ソフトウェア開発者、ドメインエキスパート)が同じ意味で言葉を使う必要がある。
さらに、ドメインの問題を解決するソリューションの作成、モデルの探求は、常に定義した言語とその進化を中心として行われる必要がある。
ユビキタスとは"in everywhere"ということである。それはつまり、ビジネスサイドの人と話すとき、エンジニアと話すとき、プログラミングをするとき、ドキュメントを書くとき、ということを意味する。
しかし、それは「全システムを通じて」ということではない。よって、正しくは"境界付けられたコンテキスト内のユビキタス言語"といわなければならない。
まとめ
いかがだったでしょうか。4つの原則を統合すると、
ソフトウェア開発者、ドメインエキスパートと共に常に同じ言語で認識を合わせ、ドメインモデルについて常に探求を続ける。
そして最終的にモデルと言語をソフトウェアにまで落としこむことを目指す。
とでもなるでしょうか。
Eric Evans本人も「明確に定義するのは難しい」と言っていたり、「DDDとは」というものに対して4つの原則(Principle)で定義するあたり、根本的にDDDというものを定義づけることが難しいものであるということなのかもしれません。
ただ、揺れる定義の中で「Eric Evansが言っているのはこうだよ」というものがあるのは、議論をするときに一つ軸として考えられる材料になるのではないでしょうか。
どう実装するのさ？については今後別途書いていこうと思いますが、その辺すっ飛ばして作ったアーキテクチャこんなんやで、というスライドがあるのでご興味ある方はどうぞ。
DDD × CQRS 更新系と参照系で異なるORMを併用して上手くいった話
用語の定義
先ほどのReferenceではDDDの定義の前に用語の定義があったので引用しておきます。
(＊1)domain
A sphere of knowledge, influence, or activity.
The subject area to which the user applies a program is the domain of the software.
知識、影響力、または活動の領域。
ユーザーがプログラムを適用する対象エリアは、ソフトウェアのドメインである。
つまり業務アプリケーションに限って言うなれば、「アプリケーションの対象となる業務領域」とでも言うとわかりやすいでしょうか。
(＊2)bounded context
A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.
特定のモデルが定義され適用される境界（通常、サブシステム、または特定のチームの作業）の説明。
共通言語はどこまで共通なんだっけ？というのを定義するという概念です。
全世界共通？難しい。会社全体で？プロダクト全体？もっと狭めてチームぐらいかな、という形に「この言語をこの意味で使う範囲はここまで」という風に決めましょうという概念です。実はDDDにとってめちゃくちゃ重要だったりします。
できれば別の記事でもう少し詳しく書きたいと思います。
(＊3)ubiquitous language
A language structured around the domain model and used by all team members within a bounded context to connect all the activities of the team with the software.
ドメインモデルを中心に構造化された言語。
チームのすべてのアクティビティをソフトウェアと結びつけるために、境界付けられたコンテキスト内のすべてのチームメンバーが使用する。
まずは「チームで使う共通言語」ぐらいの和訳でとらえておくのがわかりやすいと思っています。
後続記事
よろしければどうぞ！
【DDD】モデルでドメイン知識を表現するとは何か
もっと詳しく知りたい方は
初めてDDDを学ぶ方、もしくは実際に着手して難しさにぶつかっている方向けの書籍を出しました。
迷子になりがちな「DDDの目的」や「モデル」の解説からはじめ、
具体的なモデリングを行い実装まで落とす事例を元に、DDDの魅力や効果を体感することを目指します。
よろしければお求めください。
Twitterでも、DDDに関して発信したり、「質問箱」というサービスを通じて質問を受け付けています。こちらもよろしければフォローしてください。
また、YouTubeで10分でわかるDDD動画シリーズをアップしています。概要を動画で理解したい方はこちらもどうぞ。チャンネル登録すると新しい動画の通知を受け取ることができます