はじめに
この記事では約20パートにわたってDDD（ドメイン駆動設計）についてなるべくかみ砕いて解説します。一部説明を割愛したりして、なるべく読みやすい記事を書くことを意識しました。しかし、すべてのパートを読み終えたときには、他人に説明できるくらいになることを目標としています。また、「とりあえずなんとなくでいいから知っておきたい！」という方も気になったところだけでもいいので読んでいただけると幸いです。
なお、今回この記事を書くのにあたり以下の書籍を参考にしました。（Amazonのリンクにとびます。）
「実践ドメイン駆動設計」から学ぶDDDの実装入門/青木 淳夫
また、私独自の解釈をもとに解説することになるので、厳密な定義とは異なる言い回しを用いることも所々見られると思いますがご了承ください。🙇
では、解説に移ります！
DDDの概要
まずはじめにDDDそもそもの概要について解説します。
DDDとはドメイン駆動設計（Domain-Driven Design）のことです。2003年に海外の方が考えた高品質なソフトウェアを作成するための新たな開発手法です。
その内容を簡単に説明すると、
「顧客と開発者が共通の言語である『ユビキタス言語』で交流して、一体感のあるチームを作ろう！」
というものです。顧客について
サービスの利用者（ユーザー）とは限らず、他の開発部門のことを指すこともあります。つまり、そのシステムや業務領域に応じた広い意味をもつということである。
では、どうしてわざわざ新たな手法を提案したのでしょうか？それには明確なメリットがあるからです。
「ユビキタス言語」とは
ユビキタス（ubiquitous：偏在する）とあるように、業務や開発に関わるすべての人が、見聞きして同じ意図を連想できる一意の言葉。
これにより、コミュニケーションを滞りなく進められたり、悩むことなくコードを書けたりするようになる。
DDDを導入するメリット
メリットには以下の３つが挙げられます。
- プログラマとドメインエキスパートが「共通言語」を用いて視点を合わせることにより、１つのチームとして、まるで利用者が開発するようにソフトウェアを構築できる。
- ドメインエキスパートですら理解が浅い業務領域を深く検討することにより、業務知識をチームで洗練、共有し、理想像を検討できる。
- 「共通言語」をそのままプログラムとして実装する。「設計＝コード」と表現できるように、開発時の翻訳コストが不要になる。さらに、実装前に課題に気づくことができる。
ドメインエキスパートとは
担当業務やシステムについて一番詳しい人。職種や肩書は関係ないため、必ずしも業務担当者であるとは限らない。
また、複数人の場合もある。
補足説明
DDDは従来の「トランザクションスクリプト」ではなく、「ドメインモデル」を用いることで開発の複雑さに対処します。そのため、プログラムの記述方法が変わります。２者間の違いを簡単に説明します。
- トランザクションスクリプト
- 要求された処理をその手順で記述する。
処理単体を記述するのは簡単だが、同じようなものが増えすぎると変更のときに大変。 - ドメインモデル
- 処理をモデルとして表して、あるところで一元管理する。
はじめて記述するときは面倒だが、変化に対応しやすい。
ドメインモデル自体の定義
「モデル」とは、抽象化により不要な詳細を省くことを表す。
地名や建物名がすべて書いてある地図よりも目立つ建物のみが書いてある地図の方がナビに適しているというようなイメージ。
「ドメインモデル」はその名の通り、複雑な業務のドメインから必要なものだけを適切に抽出する方法である。
また、DDDは「アジャイル開発」を前提としています。アジャイル開発と対照的なものとして「ウォーターフォール開発」があります。両者を説明するにあたり、「リテールガイド編集部」さんの画像を借りさせていただきます。
設計、実装、テスト、リリースを何回も行うか、一回限りで済ませてしまうかの違いです。
先ほどのトランザクションスクリプトとドメインモデルと同様に、もちろんどちらにもメリット・デメリットがあるので一概にどちらが良いというわけではありません。
おわりに
今回ははじめてのDDD part1ということで、概要や周辺情報について紹介しました。次回もまたよろしくお願いします！