この記事の背景
現職では DDD を採用しており、色々な方と DDD についてお話しする機会があります。
その中で、特に初学者の方はアーキテクチャに対して「なぜこんなに面倒な事をするのか？」という印象を持たれているようでした。
そこで、DDDを採用する目的について言語化してみました。
（個人の見解なので、誤りがあればぜひご指摘をmm）
対象読者
- 基本的な用語は覚えた方
- 見よう見まねで、ある程度コードも書いた方
- 初心に立ち返って Why を理解したい方
DDDで実現したいこと
前提として、以下の要素を分けて考えます。
- ビジネスルール
- ビジネスルール以外の要素（例えばGUIやデータの保存など）
DDDでは ビジネスルールを反映したプログラムを重要なものと位置付けています。
なぜ重要なのでしょうか？
- システムは何らかの課題を解決するために存在しています
- 顧客のニーズの変化など、様々な要因で課題は変わっていきます
- 課題の変化に合わせて、解決手段であるビジネスルールも変わっていきます
- 課題の変更に対して素早く正確に対応できると、ビジネス(商売)としての競争力が高まります
- ビジネスルールを反映したプログラムは、課題解決のための手段を最も直接的に表現している箇所です
- 故に、これらのプログラムの品質を高めることが重要です
DDDで実現したい事を簡潔に言うと「ビジネスルールを反映したプログラムの品質を上げたい」となります。品質の上げ方としては、ビジネスルールを過不足なく反映することや、素早く安全に変更できる状態(保守性が高い状態)を維持すること等が挙げられます。
GUI=使い勝手もアプリケーションとしては勿論大事なのですが、相対的に見るとビジネスルールの方が大事という整理です。
DDDでは「ドメインエキスパート」「ユビキタス言語」「境界づけられたコンテキスト」など様々なワードが登場します。また、ソフトウェアアーキテクチャにおけるテクニックも色々と出てきます。これらはいずれも「目的達成のための手段の１つ」でしかないため、個別の手段に囚われて、目的を見失わないようにしましょう。
目的達成のための手段
メリットを感じるためには、手段についても理解を深める必要があります。
いくつか軽めに紹介します。
レイヤードアーキテクチャ
保守性を高めるための手段です。
プログラムの構造として、ビジネスルール以外の要素(=重要でないもの)を変更した際に、ビジネスルール(=重要なもの)への影響が出てしまう状態はよろしくありません。
例えば、ドメインモデル が DBにアクセスしてデータを取得するような構造の場合、テーブルのスキーマ変更を行うと、ドメインモデルまで修正する必要が出てしまいます。
依存性逆転の法則に沿って設計し、ビジネスルールに対してビジネスルール以外の要素が依存する構造にしましょう。
境界づけられたコンテキスト(Boundary Context)
保守性を高めるための手段です。
同じ言葉や物であっても、場面が異なる場合は別のものとして扱いましょう。
例えば、同じ「商品」であっても「注文する」時と「在庫管理する」時では、アクターも扱うデータも異なります。注文のアクターは顧客ですが、在庫管理のアクターは社員になります。商品の金額についても、注文する時は売値で在庫管理する時は原価、といった具合に関心事が異なります。これらを１つのモデルにまとめてしまうと、顧客向けの変更が社内業務に影響を与えてしまいます。
領域の区切り方は諸説ありますが、言葉に対する認識が揃う範囲で区切るのがよいかなと思います（アクターやチームなど）。
まとめ
- DDDを採用する目的は「ビジネスルールを反映したプログラムの品質を上げたい」から
- 手段を学ぶ際も、目的に立ち返ることが大事
参考文献
- エリック・エヴァンスのドメイン駆動設計