読書メモ：実践ドメイン駆動設計（IDDD）1章

はじめに

• 実践ドメイン駆動の読書メモです。簡単なまとめと、自身のコメントをまとめています。//から始まる行が私のコメントや考察。
• https://www.amazon.co.jp/dp/479813161X
• 狙い：読んだものの、頭に入ったようでまったく記憶に残らなかったため、あとで自分の記憶を掘り起こすツールとして。

第1章 DDDへの誘い

序章

• ドメイン駆動設計・DDDとは高品質のソフトウェアモデルを設計することができる開発手法である。
• DDDを用いることで、設計した結果がソフトウェアの動作を明確に表すことができるようになる。
• 戦略的モデリング、戦術的モデリングの２つのツールを用いて設計する。
  • 戦略的モデリング
    • // 本章では記述がないが、ドメインや境界付けられたコンテキストの定義などを指す。
  • 戦術的モデリング
    • // エンティティやリポジトリ…といったアーキテクチャ設計の話。

1.1 私にもできるの？

• できる。
  • // 詳細は原著を読むべきだけど、ざっくり言えばDDDに対してモチベーションを持った時点でできる。
• DDDは技術至上主義の考え方ではない。
• DDDの中心となる原則は、議論・傾聴・理解・発見、および事業価値。
  • // イケてる設計、キレイな設計、ということではなく、事業価値に重きをおいているのが重要だと思いました。DDDがもてはやされるのはここだと思います。
• ドメインエキスパートとの会話により対象の業務に対するユビキタス言語を生み出す。
  • ドメインエキスパート
    • 役職ではない。対象にする業務について詳しい人、自分より詳しい人はドメインエキスパートたりうる。

• ドメインエキスパート自身も、開発者との会話の中で対象の業務に対しての理解が深まる。

  • そこから業務の改善につながることもある。

• DDDを用いることによる立場ごとのメリット

  • 若手開発者
    • 複雑で汚いコードから目を背けたつまらない開発から開放される
  • 中堅開発者
    • より優れた熟練開発者に成長するためのソフトウェア開発技術を得られる
  • ベテラン・アーキテクト
    • ドメインエキスパートと技術者たちの間をもっと近づけることができる
  • ドメインエキスパート
    • 開発者と会話をする際に、翻訳を要さない同じ言葉で会話することができる。
      • // 開発者側がドメインエキスパート向けに言葉を選ぶのに苦労するシーンもありますね。
    • ドメインエキスパートと開発者たちを同じ土俵にのせることができる。
  • マネージャ
    • 開発者たちが業務知識を得て、業務のプロたちとの協力関係がより密接になることで、仕事が楽になる

1.2 あなたがDDDをすべき理由

• DDDをすべき理由
  • プログラマー視点だけでなく業務側の視点も踏まえたソフトウェアを作れるようになる
    • ドメインエキスパート自身がプログラミングできるとしたら作るであろうソフトウェアに近づく
  • 開発者からドメインエキスパートに対して気づきを与えることができる
  • ソフトウェアに対して開発者だけが知っているという状態をなくすことができる
  • ドメインエキスパート、開発者、ソフトウェアの間で通訳が不要な共通言語が生まれる
  • 設計がコードで、コードが設計となる
• DDDを実践するためにはある程度の時間と労力をかける必要がある
  • ソフトウェア開発にまつわる様々な課題を考えれば、その投資の価値は十分にある

• ドメインエキスパートと開発者との間の断絶は最悪の事態である

  • 向いている方向が違う
    • ドメインエキスパートは事業価値を最大化することに注目する
    • 開発者は技術的に解決しようとする
  • このため、ドメインエキスパートのメンタルモデルを反映したものではないソフトウェアができてしまう
    • // よくブランコの画像で揶揄されるコレジャナイソフトウェアのことですね
  • こうした悪例の一つとして、パッケージソフトウェアにビジネスプロセスを合わせる、というよく聞くパターンに対する警告が述べられている
    • // パッケージに業務を合わせるのではなく、DDDを用いてドメインエキスパートと技術者が協力して対象業務をより良くする方向に投資したほうが良いのだ、ということだと理解しました。
    • // 海外は業務をパッケージに合わせて最適化するのに対して、日本はSIerが個別にオーダーメイドのソフトウェアを開発しているので非効率だ、というような話がありますが、IDDDによればむしろ日本的なやり方を推奨しており、強いて言うなら「もっとうまくやる方法がDDDですよ」と言っているように感じます。例えば流通系システムを開発するときに、ドメインエキスパートと話をするコードが書ける流通系SEの組み合わせなんかはすごく上手く回りそう。

• DDDがどのように役立つか

  • 複数のドメインエキスパートおよび開発者が１つのチームとしてドメインに対する深い理解を共有できるようになる。
  • DDDは事業の戦略構想に対応しており、チーム間の組織的関係の定義や、それがもたらず悪影響に早く気づけるようになる。
    • // 業務をモデリングしていく過程で、組織的な関係もモデルとして表現された結果、使いにくいモデル≒イケてない組織的関係だと気づける、ということだと理解しました。
  • ソフトウェアに対する真の技術的要求を満たす。
    • // 「真の」というところがミソで、技術的なアプローチが先行するのではなく、そのドメインが本当に必要としている技術的な解決方法が見つかるのだ、ということだと思います。

• ドメインの複雑性に立ち向かう

  • DDDをまず導入するのは、その事業の最重要領域（コアドメイン）
  • 次点で重要な支援サブドメイン（コアドメインほどではないが、他の手段で代替できない事業領域）
  • DDDを導入するべきか否かは、その領域が「複雑≒簡単ではない」かつ価値があり重要であるかどうか
    • この複雑さの定義は会社によって違う

• ドメインモデル貧血症

  • 次のようなモデルは貧血症である
    • publicなgetter/setterだけでビジネスロジックが含まれていない
    • モデルを使う側がビジネスロジックの大半を抱えている
  • DBのレコードをオブジェクトに投影しただけのようなモデルは、ドメインモデルではない。
  • 貧血モデルが蔓延している理由
    • （特に設計に頓着していない）サンプルコードをコピペしてしまう人が一定数いる
    • 歴史的な経緯で、VisualBasicやJavaBean規格、HibernateなどのORMは「作りやすくする」ことが念頭におかれており、それらに準拠したフレームワークを使わざるを得ない状態が長く続いた
      • // 結果的に、貧血症を起こしたモデルに対して疑問を持つことのない開発者が多くなってしまった、ということだと理解しました。

• 貧血症がモデルにおよぼす影響

  • 「貧血症」のモデルは「記憶喪失」を引き起こす
    • 業務的な要件が含まれておらず、その意図が反映されていない
    • 単なるデータの入れ物、データ置き場に過ぎない
    • // 意図や要件が含まれていないので、なぜその実装になっているのか誰にもわからない＝「記憶喪失」ということだと理解しました。

1.3 DDDを行う方法

• ユビキタス言語
  • ドメインエキスパートと開発者を含めたチーム全員で作り上げる共通言語
  • ≠業界用語
    • ドメインエキスパート寄りの言葉になりがちだが、それに限定されるものではない
    • ドメインエキスパート同士でも言葉や解釈の違いがあるので、議論して作り上げていく
  • ≠ユニバーサル言語
    • 境界付けられたコンテキストの開発プロジェクト内での共通言語
    • 事業全体などで共有しようとしてもうまく行かない
• どうやってユビキタス言語を見つけるのか？
  • 最初のアプローチとしては以下が有効
    • 物理的なドメインと概念的なドメインを図示して、名前とアクションを設定する
      • UML等の形式的なものは避けたほうが良い（創造性が失われていまうため）
    • 用語集を作る
    • ソフトウェアの重要な概念に関するスケッチなどを含むドキュメントをまとめる
    • レビュー
  • 常に最新のユビキタス言語を表現するのは、チームの会話、そしてコード
    • ユビキタス言語を発見するための中間成果物であるドキュメント等はいつでも捨てられる状態にする
• 新規プロジェクトの場合は、コンテキストの境界を見つけ出すことが重要。
• // ユビキタス言語がユニバーサル言語ではない、というのはなるほどと思いました。そのチーム固有で自然と共通認識化されてる言語なので、用語集なんかを作成・メンテする必要もない、ということですね。

1.4 DDDを採用する事業価値

• （原著にキレイに整理されているので、私が特に重要だと思ったものだけ）

  • 組織のドメインに対する理解が深まり、有用なモデルが獲得できる
  • ドメインエキスパートがソフトウェアの設計に貢献できる
  • より良いユーザー体験を提供できる
    • // 技術先行で作られたシステムではなく、ユーザーの普段の業務がモデルに落とし込まれているので使いやすい、ということだと理解しました。
  • アジャイルでイテレーティブなモデリングを継続的に行える
    • // チーム全体でドメインに対する知識を深め、育てていくというアプローチがアジャイルとの親和性がある、ということだと思います。
    • // ウォーターフォール的な開発に関しても、一回作って終わり、というシステムは無いでしょうから、運用・保守をしながらドメインを育てていくことは可能だと思います。結局アジャイルだのウォーターフォールだのというのは、名前をつけて類型化しただけのものなので、アジャイルっぽいウォーターフォールや、その逆もあると思えば、スタイルにこだわるのではなく、ビジネス的にどんな課題があって、解決するためには、これこれこういう進め方が必要であり、DDDというアプローチがそれに適していそうだ、ということについての合意形成ができれば良いのではないかと思います。
  • // DDDによってより事業が最適化され、かつエンジニア目線で見ると、複雑怪奇で精神を削られるようなコードと向き合う必要もなくなるし、そういう意味でもビジネスサイドと開発サイドにとってWinWinな手法なんだなと思います。

1.5 DDDの導入にあたっての課題

• 従来の方法に比べてコスト（時間・労力）を要する
• ドメインエキスパートをプロジェクトに継続的に参加させる
  • 多忙なドメインエキスパート、システム開発以外に関心事が強いドメインエキスパートをどう巻き込む？
    • コーヒーブレイクやホッケーのチケットで釣る
    • // 要は、もくもくとコードを書くようなソフトウェアだけに向き合うのではなく、人間力を発揮してありとあらゆる方法で巻き込め、ということなのかなと思いました

• 開発者の視点を、技術偏向からドメインへと向けさせる

• 単なるデータの置き場所クラスと、振る舞いを意識したクラスの比較

• ドメインモデリングを行う理由

  • 戦術的ドメインモデリングを行うにはコストがかかる。何を基準にそのコストをかけるかどうかを判断するのか？
    • その境界付けられたコンテキストをコアドメインとして育てていく場合
      • 事業を成功させる戦略上、欠かせないものになる
      • コアドメインではないとしても、複雑かつ革新的で長期的に変化しづつけるなら
  • 扱うドメインによって、チームとしてどうすべきかを判断する必要がある
  • ポイントを個人的に重要だと思ったものを抜粋
    • ドメインエキスパートをチームに参加させられるか？
    • そのドメインが今後複雑化していきそうか？
      • 今はシンプルだが、今後複雑になる場合もある
    • 顧客にとってメリットがあるのか？
    • // 特に最後が重要だと思います。本章では、度々、DDDのメリットが事業価値の向上にあることに触れています。技術者のためのものではなく、顧客を喜ばせるためのモノづくりであり、技術偏向、開発者の視野の狭さに対する警鐘であると感じました。

1.6 現実味のあるフィクション

• 架空の企業SaaSOvation
• 今後の章ではSaasOvationのDDD導入をなぞりながら理解を深めていく

1.7 まとめ

• 以下、本章を読んだ個人的見解のまとめです。
  • // DDDの戦略的アプローチ（境界付けられたコンテキスト、ユビキタス言語）によって、「その事業が一体何をやっているのか」が言語化・定義される。その過程で、事業の最適化や、ドメインエキスパート・技術者間での業務に対する共通認識が醸成される。また、戦術的アプローチ（ドメインモデリング）によって表現されたコードは、ドメインに対する矛盾がなく、コード自体に要件やビジネスの概念が落とし込まれているので、理解しやすく、変更に強いものとある。
  • // 技術者は技術偏向な考え方を改め、対象のドメインに目を向け、そのドメインが本当に必要としている技術的課題を探すべきである。ドメインエキスパートと開発者が「彼ら」と「私」という異なる存在ではなく、まとめて「私たち」である必要があり、一つのチームとして、ビジネス的な課題に立ち向かう必要がある。
  • // DDDの導入にはコストがかかるが、そのドメインが複雑になる可能性や、今後成長していくものであれば、そのコストをかける価値がある。

さいごに

• Evans本に比べるとわかりやすいという触れ込みですが、それでも漫然と読んでいると頭に一切入ってこない印象です、なんとかこの調子で読破できるようにがんばります…！
• 何か解釈に関してご意見などありましたら、コメントいただけると幸いです。