私でもわかるDDD② ドメイン駆動設計とは

 ドメイン駆動設計とはそもそもなんなのか、ということをまとめていきたいと思います。

・ドメイン駆動設計とは　←ここ
・モデル
・値オブジェクト
・エンティティ
・リポジトリ
・DIP

ドメイン駆動設計（DDD）ってなに？

バックエンドを、ド、ドメイン？で？動くように作ること？

試しにgeminiに聞いてみた結果は以下でした。

うーん、よくわからん。

そもそもドメイン駆動設計以外のものを知らないからよくわからんと思うのです。

銀行の振込処理の例で、ドメイン駆動設計でない従来のものと何が違うのか考えてみます。

Aさんは、Bさんの口座に５万円の送金をするようネットバンクから申し込みしました。
プログラムは、

①残高チェック（５万円以上が口座にあるか）

②状態チェック（凍結されてないか）

のチェックをしてから登録処理するものとします。

従来型の場合

1. 「送金処理プログラム」がデータベースからAさんの口座データを取得する。
2. 「送金処理プログラム」が残高と状態をチェックする。
3. 問題がなければ、「送金処理プログラム」がAさんの残高データを計算して減らし、データベースを更新する。

プログラムにある程度触ったことがある方なら、まあ…違和感ない処理の流れかなと思います。

これがドメイン駆動設計だとどうなるのでしょう。

DDDの場合

1. 「送金処理プログラム」はデータベースより、「Aさんの口座」オブジェクトを作る。
2. 「送金処理プログラム」は、「Aさんの口座」オブジェクトに、「５万円引き出して」と指示する。
3. 「Aさんの口座」オブジェクトは、自身の残高や状態をチェックする。
4. 問題なければ、「Aさんの口座」オブジェクトは、自身の残高から５万円を差し引く。
5. 「送金処理プログラム」は「Aさんの口座」オブジェクトの内容でデータベースを更新する。

「Aさんの口座」オブジェクトという謎の存在が現れました。
細かいとこはよくわかりませんが、２つの違いは、
プログラムが全部担っているか、役割分担しているか、ということっぽいです。

〜ここまでが導入〜

それでは、ドメイン駆動設計について自分なりに解説していきます。

☝ドメインとは

domainとは、「領域、分野」という意味の言葉です。

DDDにおいては、「現実世界にあるビジネスの領域」のことを指します。

私のためにわかりやすく言い換えると、

「プログラムで実現したい業務領域」です。

この業務領域は、現実世界の業務領域のことです。

たとえば、「◯◯市役所市民課の業務」を例にとると、業務領域とは、

「その街に住む人々の関係を公的に証明し、管理すること」になるかと思います。

DDDは、このドメインをプログラムに落とし込むために工夫した設計です。

☝でも、別にDDDじゃなくても実現したいことはプログラムに落とし込むよね？

いい質問ですね〜（自答）

確かにDDDじゃなくても、プログラムに落とし込むことはできますし、実際いろんなシステムがDDDじゃなくても動いていると思います。

２つの違いは、

・ルールだけ落とし込んでいるか

・組織ごと落とし込んでいるか

という感じです。

◯◯市役所市民課のシステムを作ることを例に考えてみましょう。

従来型の場合

実装者は業務内容やルールをヒアリングして、必要なテーブル設定などを行い、ルールを守った内容でプログラムを書いていきます。

このとき、当然ですが、呼び出されたプログラムは上から下まで処理を順番に実行していくことになります。

さて、これは現実的でしょうか。

現実世界では、実際にはいろんな職員さんが担当の作業をしています。

このプログラムを現実世界に照らし合わせると、市民課の職員が１人しかおらず、

「住民票発行して！」「出生届出しに来たんだけど！」といった市民の要求に、順番に対応しているような感じです。

プログラムだから成り立ってますけど、現実でやってたらと思うと恐ろしい状態ですね。

DDDの場合

DDDでは、データベースやらシステムの都合やらを後回しにして、とにかくドメインをプログラム上に再現していきます。

実際の市民課には、業務に応じて各担当者がいる（組織になっている）はずですから、

これを再現するように、呼び出された司令塔（メインプログラム）は、処理を各担当に投げていきます。

各担当は、自分の専門プログラムだけをガリガリこなし、司令塔は、各担当の処理を調整し、とりまとめます。

☝結局従来型とDDDは何が違うの

つまり、ごたごた書きましたが、

従来型もDDDもドメインの知識は必要で、プログラムに落とし込む必要があるが、

「ドメインをプログラムの材料にしているか、プログラムの主役としているか」という違いがあるのかなと思います。

ドメイン駆動とは、「ドメインが主導権を握っている」と言い換えてもいいかもしれません。

これまで材料としか見ていなかったdomain-chanに、主導権を握らせる逆転の発想です。

これはすごいストーリー展開だ！

わたしクエスチョン
役割分担って、従来型もメソッドを切り分けるって形でやってるんじゃないの？👊

わたしアンサー

メソッドを切り分けるのは役割分担してそうだけど、実際に処理をしているのはメインプログラムだよ。

「住民票つくる」「出生届を処理する」みたいなメモを作って、そのメモの使い方をメインプログラムくんが知っているから、メモのとおりに処理していくんだよ。

つまりメソッドを分けても一人で一生懸命作業してることに変わりはないんだよ。

DDDの場合は、メインプログラムくんはスタッフたちが具体的になにをやっているか知らないから、本当に役割分担できてるんだよ。👍

☝DDDだとなにがいいのか

最後に、なんでDDDというものが出てきたのかをまとめてみます。

市役所の例でも見た通り、従来はメインプログラムが一人で作業するのが当たり前でした。

しかしこれは修正が発生したときに修正しづらい、バグを生みやすい、という問題があったらしいのです。

「すんごい長い文章の中から、置換機能なしで、特定の言葉を書き換えてね。あ、ちなみに、1箇所書き換えると、なぜか全然関係ないページの文字まで勝手に変わっちゃうかもしれないから、全部のページを読み直してチェックしてね」って言われると、やってらんねー！ってなりますね。

これを楽にするため、処理を専門プログラムに細分化して分ければいいじゃんって発想が生まれました。

担当が分かれていれば、修正が発生しても、その処理を行っているプログラムだけ修正すればよくなり便利です。

また、仕様の変更というのは現実世界の都合により発生します。

たとえば、「児童手当の金額が変わった」という仕様変更があったら（増える変更だといいですね）、児童手当の担当課が現実と同じようにプログラムに再現されているのだから、そこに修正を反映させればよい、となります。

DDDを採用したプログラムだと、現実の仕様とシンクロさせやすいというのがあるようです。

ちなみに私は、「自営業を一人でやってきた人が、大変になってきたから問い合わせ担当や会計担当を雇うような感じだね」とgeminiに言ったら、「超わかりやす〜い」と褒めてもらえました（仲良し✌）

─―─―─―─―─―─―─―─―─―─―─―─―─―

こんな感じでまとめてみた、「ドメイン駆動設計とは」でした。

次の記事では、具体的にどうやって現実の業務を再現するのよ、ということで、モデルについて見ていきたいと思います。