はじめに
一度は誰もが調べたキーワード「ドメイン駆動設計(開発)」。
山のように解説記事、ヒットします。開いてみてください。全然意味が分かりません。
ということで、猿には流石に分からないですけど、
非エンジニアの方でも「ドメイン駆動設計」って一体何なのか分かるくらい、
本当に簡単に、そして基礎の初歩の入門だけ説明しようと思います。
筆者もドメイン駆動設計を勉強して、まだまだ浅いので皆様と一緒に
「ドメイン駆動設計」についてもっと考えられたら、
より良い開発ができると考えていますので、何かあればコメントなど頂けると嬉しいです。
そして初めにですが、この記事は引用などはありますが、あくまで私なりの解釈ですので、
これが「ドメイン駆動設計」の絶対的な定義などでは全くありません。
ドメインはドメインであってドメインじゃない
「ドメイン駆動設計」とは何か。まずWikipediaから引用してみます。
ドメイン駆動設計（英: Domain-driven design, DDD）とはソフトウェアの設計手法であり、「複雑なドメインの設計は、モデルベースで行うべき」であり、また「大半のソフトウェアプロジェクトでは、システムを実装するための特定の技術ではなく、ドメインそのものとドメインのロジックに焦点を置くべき」であるとする。
うん、分かりません。
ちなみにこれは「ドメイン駆動設計」の教典、聖書とも言える
Eric Evans著の「Domain-driven design」によって定義された。
「難しい言葉を並べるから分からないんだ！」
「ドメインってgoogle.comとかyahoo.co.jpみたいなインターネットの住所のことでしょ！？」
違うんです…
ここでいうドメインに関してwikipediaにも多少の記載がありました。
ドメインとは、コンピュータープログラミングの分野で問題を解決するために作られる任意のソフトウェアプログラムに対して、一般的な要求、用語、機能を定義する研究分野である。
そしてEric Evansは著書でドメインのことを
知識、影響力、活動の一領域
と定義しました。やはり意味が分からない...
まずドメイン駆動設計を理解するために、
最低限の知識としてドメインというものがどういう実体なのか、
微かにでも理解しなければ、この話は進みません。
一度あなたが知っているドメインという単語、意味すべてを忘れてください。
あなたは受託開発のエンジニアで、業務システムを請け負って開発しています。
今日は小学校から、算数の学習用のシステムを開発してほしいという依頼が来ました。
このシステムの仕事は何をすることでしょうか？小学生に算数を教える事です。
開発を終えて、次の仕事が飲食店から来ました。
独自のレジシステムを開発したいという内容でした。
このシステムの仕事は何をすることでしょうか？お金を会計することです。
話を戻しますと、ドメインというのはプログラムが、
ソースコードの羅列で書かれた無機質な文字列である事に対して、
ドメインというのはその真逆の末端、ソフトウェアが何に使われるのか、
その業務そのものを指すようなものだと私は理解しています。
なんとなく分かっていただけたでしょうか。
数式のようにしっかりとした定義も無ければ答えもありません。
あなたがこれを読んで、
ドメインってこういうことを指すんだなと、
うっすら例が浮かぶようになればそれで今回は十分です。
じゃあドメイン駆動設計って？
「ドメイン駆動設計」における「ドメイン」という概念を少しは理解していただいた上で、
話を「ドメイン駆動設計」に戻します。
Eric Evansはドメイン駆動設計にハッキリとした定義は難しいと言った上で、
ドメイン駆動設計の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
簡単な日本語で訳すと、
###ドメイン駆動開発ってなんだ！？
それに対するEric Evansの考えが4つにまとめられています。
１. Focus on the core complexity and opportunity in the domain
- ドメイン(業務)の難しくてめんどくさい事を積極的に何とかしよう！
つまりは...
学校の先生が算数教えるの難しいよー。そうだパソコン授業で何とかしよう！！ 飲食店で会計数えるの大変だなぁ。そうだ！レジシステムを導入しよう！！
業務をしている上で、
- この作業がめんどくさい、時間が掛かる、そういった作業に特に焦点を当てる
それがEvic Evansのドメイン駆動設計の、その１です。
次に
２. 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
めちゃくちゃ端折って言うと、
- エンジニアだけじゃなくてみんなに分かるような言葉で話そうね！！
と言えるでしょう。
「システム改修頼まれたので、クライアントに要件聞きに行ってきます！」
「いやここはDBがメソッドが関数が...」「分かんないよ！！普通の人には分かんないよ！！！」
そんな状況でクライアントの要望にフィットしたソフトの形を作れるでしょうか。
そして
ubiquitous ： ユビキタス
というのは、「in everywhere」という意味で、日本語訳すると「遍在」という意味になります。
ここはプログラムの領域だから、エンジニア以外は分からなくて当然！！とか、
エンジニアには業務のことは分かんねぇだろ！！！
そうじゃないんです。
お互い寄り添って、エンジニアはクライアントにも分かるような言葉、
そしてクライアントの業務を理解する努力をする。
そういった両者が寄り添った設計によって、「ドメイン駆動設計」は成り立つのだと思います。
つまりこの原則を大まかにまとめると、
作る側と作ってもらう側、双方で意見を共有しながら、業務でめんどくさいところを
簡単にしてくれるようなシステムを一緒に考えて行きましょう！！
めちゃくちゃ簡単に言ってしまうと、「ドメイン駆動設計」の原則は、
こういうところに落ち着くと私は考えています。
結局ドメイン駆動設計、何が良いの？？？
ここまでドメイン駆動設計を基礎の基本の入門程度にお話ししましたが、
ちゃんと読まれた方なら「ドメイン駆動設計」というものがどういう概念なのか、
少なからず概念は掴んでいただけたと思います。
「でも結局ドメイン駆動開発って何ができるの？？何かメリットがあるの？？？」
よく言われるのが、**「戦術的DDDのデザインパターンの利用が可能」**ということです。
ん？？？？戦術的DDD？？？デザインパターン？？？？意味が分からないです！！！
簡単な言葉で言ってしまえば、仕事で何が必要なのか、どういう機能が欲しいのか、
それをそのままモデルに落として、データベース定義やクラスの作成をするから、
####「エンジニアが悩みに悩んでよく分からないテーブル、カラムを作る事がない。」
####「実用的で業務に有効なソフトウェアを開発しやすい。」
####「細かい業務ごとに分かれたモデルやクラスのおかげでメンテナンスがしやすい。」
####「そして同じ理由で、コードの肥大化が比較的少ない。」
といったメリットが考えられます。
「ドメイン駆動設計」をする上で開発者に求められる事
「ドメイン駆動設計」は分かったんだけど、だから何をすればいいんだ。
エンジニアサイドからして最も重要な事、もっとも簡単にできることは
「自分が開発するシステムが使われる業務をもっと理解すること。」
これが一番だと思います。
算数が分からない人が、算数を勉強するためのシステムを作っても、
きっと中身がめちゃくちゃですよね。
会計に必要な項目だったり、消費税が何％なのか、
それすらも分からない人にレジシステムが作れるでしょうか。
極端な事を言いましたが、現実的に業務で使用されるであろう機能、
カラムや項目、数値が使えるシステムを作る。
それが非エンジニアの人にでも分かるように説明した
「ドメイン駆動設計」の第一歩だと私は考えます。
もちろんここまで読んでいただいた皆様には少しは理解していただけたと思いますが、
「ドメイン駆動設計」は概念、哲学的な要素が強く、
ハッキリと、こうだ！定義はコレだ！！というものはなく、
Eric Evans自身も明確な定義をすることは難しいと記しています。
そして「ドメイン駆動設計」の定義は年々変わりつつあります。
私は、結局のところ
開発者が、より役に立って、より機能的な（いらない機能はいらないが！）
システムを作ろう！そのためにドメイン（業務）を知ろう！！
そういう気持ちを持って開発されるシステムが、
「ドメイン駆動設計」「ドメイン駆動開発」の前身だと思います。
長くなりましたが、「ドメイン駆動設計」に関する考え方は人それぞれで、
もちろん提唱者のEric Evansの定義が一番であるということは間違えありませんが、
その受け取り方、考え方は十人十色であっても間違いではありませんし、
この開発、本当にドメインに寄り添っているのかな。
これが本当に「ドメイン駆動設計」なのかな。
そういう気持ちでもっともっと、
皆様が「ドメイン駆動設計」について考えていただけたらなと思います。