弊社ではソフトウェア開発において「モデリング」に力を入れているのだが、そんな折にかなり良さそうな書籍が出版された。
元より私が「ドメインモデリングとオブジェクト指向プログラミングを一体化して考えるべきではない」「微細なドメイン内部のモデリングを完璧にしようとするあまり、よりユーザーに近いユースケース/アクティビティ/ワークフローといった大局を疎かにしてはいけない」といった主張を社内でしていた事もあり、こういった考えと親和性が高そうなこともあって、会社的に勉強会を開く事にした。
詳しい内容は是非とも書籍を読んでほしいので割愛するとして、以下に読んで率直に感じたことを各節ごとにいくつか書いていく。（今回は第一章のみ。以降は他の弊社メンバーによって持ち回りで書いていく予定）
- 1 ドメイン駆動設計の紹介
- garbage in , garbage outのgarbageを減らすことがドメイン駆動設計であること、そしてドメイン駆動設計とオブジェクト指向設計が異なることが示唆されている。ともすればDDDの実践=OOPによる実装でそのイメージを持たれがちなのだが、前述の通り私はそのような風潮には明確にNo!の立場。
- 実際のところ、この一章を読むだけでも結構DDDの本質について知見が得られると思う。
- 1.1 モデルを共有することの重要性
- ドメインエキスパートと開発チームがモデルを共有しない場合、間にアナリストだのアーキテクトだのといったわけのわからん存在が居ると伝言ゲームの発生により問題理解のミスマッチのリスクが高まる。
- アジャイルな開発プロセスでドメインエキスパートと開発者が密に連携するだけでは不十分な事もある。
- よって、共通のメンタルモデルを構築してソフトウェアモデルとビジネスドメインを一致させていくことが重要。
- モデリングの本質は極めて人間的な営みであり、OOD/OOAなどに偏った言説がいかに的外れ（こう言い切ってしまおう）かが窺い知れる。
- 1.2 ビジネスイベントによるドメインの理解
- 本書ではまずドメインモデルの前にビジネスイベントとワークフローに焦点を当てている。これはビジネスというのはデータを持っているだけでは価値があるわけではなく、データ変換の連続の中で価値を創出するものであり、その契機となるのがビジネスイベントであるため。これは毎日一定の時刻に行う業務であったり、メールや電話であったり様々。
- こういったイベントを設計の一部として表現することが重要で、これを「ドメインイベント」と呼ぶ。
- ドメインイベントやワークフローを発見する手法の一つとして、プロジェクト関係者（※開発者やドメインエキスパートに限らない）を集めたワークショップを開き、思いついたイベントとそれにより発生するワークフローを列挙するというのが挙げられている。（イベントストーミング）
- これを怠った結果とんでもないモデルが出来上がった経験があるので、これはできるだけ速やかに取り入れていきたい。
- 1.3 ドメインをサブドメインに分割する
- 「そもそもドメインとは何か？=ドメインエキスパートが専門としている物事」ただそれだけ！明快！
- 1つのドメインは小さなサブドメインに分割できる事がある
- 例えば「プログラミング」は「Webプログラミング」「システムプログラミング」「××言語プログラミング」などと分けられる
- Webプログラミングの中にはJS/TSによるフロントエンド開発もあれば、バックエンド開発もある
- フロントエンド開発の中にはCSS系の技術もあり、それらはWebデザインという別のドメインと被っている部分がある
- 上記のプログラミングの例を見れば明らかだが、現実にはサブドメイン同士が重なる部分があったり、その重なりを通じて別のドメインと節ぞk素有れたりする。
- 適切なサブドメインの分割のためには、開発者自身もある程度ドメインエキスパートになる必要がある。（やはりここでもメンタルモデルの共有の重要性に行きつく）
- 1.4 境界付けられたコンテキストを利用した解決手段の作成
- 恐らく一番重要な事：「問題空間と解決空間を分ける」
- 問題空間とは現実世界のことであり。そこでのドメインの境界は必ずしも明瞭ではない。
- 解決空間とは問題空間のドメインに対応したドメインモデルの世界であり、そこでの個々のドメインは明快に境界が分かれている。
- これはサブシステムやモジュールの間の依存関係を可能な限り減らすという標準的なお作法の延長線上の話。
- この時、必ずしも問題空間のドメインと解決空間のドメインは一致しない。問題空間のドメインが複数の解決空間のドメインに分割されることもあれば、逆に解決空間で複数の問題空間が統合されることもある。
- コンテキストを正しく区別するために色々なガイドラインが示されているが、設計が多少煩雑になったとしてもワークフローのスムーズさを優先し、ビジネスおよび顧客の価値に焦点を当てろと書かれているのは特に好印象。この意識を無くすと悪い意味でオタクな設計に走りがちな事もあるので……。
- 「コンテキストマップ=境界付けられたコンテキストの間の関係性の記述」
- 本書で示されているコンテキストマップはまさにグラフであり、グラフDB製品を開発して業務で用いている弊社メンバーであれば、グラフDBとモデリングの延長線で理解するのも良いかもしれない。
- 1.5 ユビキタス言語の創造
- 「ユビキタス言語=チームの全員が共有する語彙と概念のセット」
- ドメインエキスパートのメンタルモデルに存在するものと設計に存在するものは一致しているべきであり、ドメインエキスパートのメンタルモデルに存在しないものを設計に含めるべきではない！
- ユビキタス言語に含まれているある概念がモデルのどこにも現れないモデリング結果と格闘したことがあるが、まあなんというかその、大変。
- ユビキタス言語の創造はチームメンバーの共同作業であり、ドメインエキスパートが天下りに与えるわけではない。また、静的なものではなく絶えず更新されるものでもある。
- また、コンテキストによって同じ言葉が別の意味を持つこともしばしばあるので、ユビキタス言語はコンテキストが与えられて初めてそのコンテキストの中で意味をもつと捉えた方が良いと思う。（これは数学的な考えかも。）
- システム開発の話ではないが、このコンテキストが違う事で言葉の意味が変わる事で起こった悲劇的な事故に有名なものがある。歯科医の世界での「フッ素」と、歯科技工（入れ歯とか作る仕事）の世界の「フッ素」がそれぞれ「フッ化ナトリウム」と「フッ化水素酸」を指すらしく、その取り違えで死亡事故が起こったというのだ。
- 私自身、交通インフラなどの人命に直結するプロジェクトに携わった事もあり、こういったコンテキストの変化による言葉の意味の変化には十分に気をつけねばならないな、と改めて思う。
- 1.6 ドメイン駆動設計の要約、1.7 まとめ
- 総まとめの章なので割愛