ドメイン駆動設計はじめました
ドメイン駆動設計を読んだ感想
この本を読む前までのなんとなくの印象ではドメイン駆動設計(以下DDD)というのは、アーキテクチャの話だったりデザインパターンのような実装方法のことだと思っていました。
しかしDDDという設計手法は
-
業務領域から競合他社との違いを生み出す業務活動である「中核の業務領域」を見極める
-
一貫した「同じ言葉」を定め使用することで業務エキスパートと開発チームの業務活動への知識を合わせ共通理解を生み出す
-
同じ言葉が通用する範囲で境界を決め、事業活動の「区切られた文脈」を定める
上記のような開発以前の認識合わせが重要になるもので、開発の話は上記を具体化するために必要なものだと認識しました。
もちろんDDDを実現するためのアーキテクチャ設計など実装方法の選択も重要ですが、まずは業務領域への向き合い方を変えることが重要だと感じました。
中核の業務領域の特定
DDDでは業務領域を以下の3つのカテゴリーに分類します。
-
補完的な業務領域
中核領域を実現するために必要ではあるが直接利益を生むわけではない領域。
この領域は単純なCRUDで実装できる機能であり、参入障壁を作る必要はない。 -
一般的な業務領域
会計業務など多くの会社で同じやり方をしていて既存のサービスを利用できる領域 -
中核的な領域
競争優位を生み出すための領域。
中核領域を見極めることでリソース配分を最適化できます。さらに中核領域の拡張性の向上を意識して設計することでビジネスの成長に伴う変化に対応が可能になります。また必要かもしれないと思い作られた機能があまり使われなかったり、実は補完領域に含まれる単純な実装で問題のないはずの機能を作り込んでしまうということが防げるのではないでしょうか。
同じ言葉
一般にユビキタス言語と言われる概念ですが、この本ではわかりやすさのため同じ言葉と呼ばれています。
同じ言葉とは業務エキスパートが使用しているものと同じ言葉を使うことで業務知識への共通認識を生み出すためにあります。伝統的な開発の進め方では開発者向けの仕様書を作成し、それをコードに落とし込むという方法をとることが多いですが、それでは業務知識が伝言ゲームのように伝わってしまい本来の課題とは違うものを開発してしまうということが起こりえます。同じ言葉を使用することで業務知識や課題の共通理解を生み、本質を捉えた課題解決ができます。
ここで注意が必要なのが同じ言葉を組織全体で統一する必要はないということです。見込み客という言葉を営業部門とマーケティング部門が別の意味で使っている場合（本のなかで使用されている例えを使わせていただきます）、それぞれ区別して扱うべきです。ただし同じ言葉を異なる意味で使い分けるのは認知不可が高いのが問題です。区切られた文脈によってこのような状況をうまく扱うことができます。
区切られた文脈
区切られた文脈とは、端的にいうと同じ言葉が通用する範囲を指します。先ほどの例だと営業部門とマーケティング部門では見込み顧客という言葉の意味が違うので、営業部門とマーケティング部門の間には境界があるということになります。この境界の決定こそがシステム設計の本質です。
本ではこのように述べられています。
アーキテクチャの選択はシステムの設計です。システムの設計は文脈の設計です。文脈の本質は境界です。境界の内側に何があり境界の外側に何があるか。境界を超えて、どう繋がり、何が移動するか。何を選択肢、何を諦めるか。境界は、何が外部であり何が内部であるかを明らかにします
一つの業務領域でも課題が複数あれば別々のモデルが必要だと考えるべきであり、業務領域に対してモデル（区切られた文脈）を一対一に限定する必要はないということです。
また以下のようにもモデリングについて述べられています。
ドメイン駆動設計の区切られた文脈は、言語学の「意味論的な領域」に基づいていると言えるでしょう。意味論的な領域とは、言葉が同じ意味で使われる範囲、あるいは、その内部で同じ意味で使われる言葉の集合を指します。
モデリングの重要性
モデルは特定の課題を解決することを目指し、その目的に沿った情報だけを提供しなければなりません。
例として自動車について考えてみると、ユーザーの視点からみると移動、運搬が主な目的となるので燃費、広さ、積載量、故障しずらいこと、などが必要な情報であり、逆にエンジンを設計した企業、部品の生産地などは不要な情報となります。メーカーの視点からみると調達を安くしたい、他社より性能を上げたいという目的から部品の素材や製造した会社などが必要な情報となると考えられます。
課題に対するモデリングがずれていると、ビジネスの要件が変化した際に迅速に対応できず競争優位性が損なわれる結果になる可能性があります。
疑問点など
実装の話だけでなく根本の組織づくりや考え方などDDDの本質を学べるすばらしい本だと感じました。
一方で業務エキスパートとの密接な連携が取りづらい場合どのようにDDDを取り入れればいいのかについて疑問が残ります。
例えば私が今所属している会社ではユーザーの要望をPdMチームが聞き取り、機能要件までを定義してからエンジニアと連携し開発に入っていく形式をとっています。このような場合、たとえエンジニアチームがDDDを学んだとしても組織にその考え方を浸透させるのはむずかしいことなのではないかと感じます。よく言われるDXが難しい理由と同じように上層部がエンジニアチームに理解を示し、組織改革を実行できる組織でなければ真にDDDの価値を発揮することは難しいのではないかと思ったのですが、実際にDDDを成功させている事例を調査して理解を深めてくしかないところですね。
今回はしませんでしたがEntityやAggregate,アーキテクチャの選定等についても考えたいので次はDDDの実装の記事を書きます。
Discussion