［WHAT］ドメイン駆動設計の概要
それでは、IDDD本、1章の「DDDへの誘い」の紹介に入ります。
DDDは「高品質」のソフトウェアを設計する手法です。ここでの高品質はバグのないという意味ではなく、ビジネス的にも成功していることを指します。技術至上主義ではなく、「事業を理解し、チームの知識を1つにまとめる」ことを重視します。それを「ユビキタス言語」と呼ばれるチームの共通語としてプログラムを実装します。
つまり「ドメイン駆動設計」とは『顧客と開発者が共通言語で会話して、一体感あるチームとして、事業価値の高いソフトウェアを開発する手法』と言えます。
［WHO］DDDを始められる人とは
DDDは誰でも取り組むことができます。ソフトウェア開発の現場には様々な不満が存在していますが、現状を変えたいという情熱がある人であれば誰でもDDDを始めることができます。例えば次の役割の人がDDDに取り組むことができます。
| 役割例 | 不満 | 要望 |
|---|---|---|
| 若手開発者 | 全体が理解できず単調な詰め替えコードを書く仕事がつまらない。 | クリエイティブで面白い開発をしたい。 |
| 中堅開発者 | 暫定対応ばかりで疲弊している。 | 適切なソフトウェア開発をしたい。 |
| ベテラン開発者 | ビジネス的な価値を発揮できていない。 | 開発者とビジネス側との距離を縮めたい。事業価値を出したい。 |
| ドメインエキスパート（コラム参照） | 開発者と会話がかみ合わない。ソフトウェアが思った通りに動かない。 | 開発者とスムーズな会話をして良いソフトウェアを作りたい。 |
| マネージャ | 開発者は熱心に技術を学んでいるが結果が出ていない。 | 開発者が業務知識を得て、ドメインエキスパートと協力して結果を出してほしい。 |
どの役割の人も「良いソフトウェアを作りたい」と考えているものの、多くの不満を抱えています。DDDを採用することで、これらの課題を解決します。
ドメインエキスパートとは
ドメインエキスパートとは、担当業務やシステムについて一番詳しい人を指します。職種や肩書に関係なく、対象領域について一番理解している人です。
そのため顧客や業務担当者に限らず、社長、役員、営業担当、SE、プログラマの場合もあります。また一人とも限らず、複数の場合もあります。
［WHY1］DDDを導入するメリット
続けて、DDDを導入する理由について見ていきます。
まず、DDD導入のメリットとして以下の3つが挙げられます。
- プログラマーとドメインエキスパートが「共通言語」を用いて視点をあわせることにより、ひとつのチームとして、あたかも顧客が開発するようにソフトウェアを構築できる。
- ドメインエキスパートですら理解が浅い業務領域を深く検討することによって、業務知識をチームで洗練／共有し、理想像を検討できる。
- 「共通言語」をそのままプログラムと実装していく。「設計がコードであり、コードが設計である」と表現されるように、開発時の翻訳コストが不要になる。合わせて、実装時の課題に設計段階で気づくことができる。
これらをまとめると、DDDのメリットは「顧客と開発者がひとつのチームとなり、設計と実装をひとつのソフトウェアとして構築できること」といえるでしょう。
［WHY2］開発費用を「コスト」から「事業投資」へ
次にDDDを導入する理由として、「システム開発費用の考え方を変えること」ができます。従来の開発では、顧客から聞き出した仕様をプログラマが翻訳するという片道通行でしたが、DDDでは、共通言語を用いて一緒に議論する双方向開発を行います。ソフトウェア開発を、開発者視点から顧客視点へ揃えることで、ビジネス的な価値、事業価値を高めることができます。その結果、開発費用を「無駄なコスト」から「事業投資」への扱いに変化させることができます。
［WHY3］ドメインモデルによる「複雑さ」への対処
最後にDDDを導入する理由として、困難なシステム開発において「技術的な解決手法が提示されていること」が挙げられます。ソフトウェア開発が難しい理由のひとつとして対象領域の「複雑さ」にあります。DDDはこの複雑さを「ドメインモデル」を用いて対処します。そのため、DDDではプログラムの記述方法が変わります。
多くのプロジェクトでは、要求された処理をその手順で記述する「トランザクションスクリプト」と呼ばれる実装を用いています。しかし、DDDでは、業務をオブジェクトの振る舞いとして表現する「ドメインモデル」として実装します。これによって、UIやリクエストに依存した設計ではなくなるため、計算処理や妥当性チェックのようなビジネスロジックが適切な箇所で一元管理されます。
なお、単純なマスタメンテナンスや30程度のユースケースフローでは、DDDを導入するコストのほうが高く付きます。最初から複雑だとわかっているシステムや、将来的に複雑に成長していくことがわかっている場合に、DDDを採用するメリットがあるといえます。
ドメインモデルとは
「モデル」という言葉は、抽象化によって不要な詳細を省くことで、問題を解決することを表しています。例えば、詳細すぎる地図では情報が多すぎるため、道に迷ってしまうことがあります。逆に上手に抽象化した地図では、確認が必要な建物のみが表示されています。「ドメインモデル」はその名の通り、複雑な業務ドメインの中から、システムに必要な概念を適切に抽出する方法となります。
