「ドメイン駆動設計をはじめよう」を読んだ
この記事は何か
最近、翻訳版が発売された「ドメイン駆動設計をはじめよう」を読んだので、その感想を書きます。
TL;DR
平易な翻訳になっているため、初学者にとって馴染みやすい内容だと感じました。
内容に関して疑問の残る点もありましたが、それは本書というよりはDDDの課題ではないかと思います。
DDDを学習したい人にとってはおすすめの書籍です。
私がこの本を読む前に読んだDDD関連の書籍
エリック・エヴァンスのドメイン駆動設計
Domain Modeling Made Functional
ドメイン駆動設計 モデリング/実装ガイド
※ 実践DDD本は読んでいません。
書かないこと
- DDDとは何か
- 書籍に書かれていた内容の詳細な説明
本書の内容
翻訳者の増田さんの概要スライドをご参照ください。
さらに詳しく知りたい方は実際に本を読んでいただきたいと思います。
訳語について
本書ではDDDで従来使われていた訳語とは異なる訳語が使われています。
その訳語を使ってDDDを定義すると以下のようになります。
かなり親しみやすい表現になりましたね。
この翻訳は、従来のDDDの訳語とは大きく変えられていたため、いくつか批判も見受けられましたが、私はこの訳語には肯定的です。
理由は以下の3つです。
- 本書内で従来のDDDの訳語の対応が明記されているため、この本の内容と他の書籍の内容を対応付けることは容易なこと
- 従来のDDDの訳語の難解さから初学者の学習を妨げたりコミュニケーションをかえって難しくしてしまうこと
- 本書は「はじめよう」とあるように、初学者への導入の書籍であり、より詳しく知るために他の書籍への導線も用意していること
私個人としてはDDDの単語の難解さから誤解を生んだり、導入の難しさを感じる場面を経験したことがあるため、このように考えています。
本書はDDDの実践を通して、導入の難しさを経験してきた著者がその経験をもとに現実のチームでDDDを導入するための観点が多分に含まれている書籍であることから、著者の意図にも反さない訳語であると思います。
実際に翻訳者の増田さんは著者のVlad Khononovさんに了承を得て訳語を変更しているとのことです。
特に「ユビキタス言語」が「同じ言葉」になってることが好印象でした。
私自身もDDDの「ユビキタス言語」をイメージしながら「同じ言葉」を使うという表現をすることが多かったため、この訳語の変更には大いに共感しました。
第1部 設計の基本方針
第1部はDDDの最も重要な考えである、開発者が事業活動を理解することの重要性と、その観点について述べられています。
DDDの他の書籍と大筋は同じですが、本書特有の平易な訳語のおかげで直感的に理解しやすい内容になっています。
また、複数の具体的な事例が例示されているため、より理解が深まりやすいと感じました。
第2部 実装方法の選択
第2部では、DDDの実装方法について述べられています。
第1部で説明された、中核か否か、データ構造は複雑か、お金を扱うか、分析・監査があるかなどを元に、トランザクションスクリプト、アクティブレコード、ドメインモデル、イベント履歴式ドメインモデルの4つの実装方法から選択するという考え方が示されています。
第2部は個人的には、いくつか疑問が残る内容でした。
まず、中核ではない業務領域でデータ構造が複雑な時にはアクティブレコード[1]を選択するという考え方についてです。
利用する言語によりますが、多くの場合、アクティブレコードパターンを採用することはアクティブレコードのORMを利用することが前提となります。
ORMによってはアクティブレコードを使わなくても複雑なデータ構造を扱うことができます。Prismaなどはその典型です。
ORMについては言語やフレームワークによって所与のものであることが多く、いづれにせよ、手続的なコードを書くことになるため、トランザクションスクリプトであると割り切ってしまった方が、余計な迷いがなくなり、話がシンプルになると感じました。
また、古いオブジェクト思考に基づいた実装方法が含まれてしまっている部分を差し引いて読むべき箇所が含まれています。
特に値オブジェクトの等価性を==記号で判定するためにEqualsメソッドをオーバーライドするという部分は、現代の言語やフレームワークにおいては適切な方法ではないと感じました。
ある程度アップデートはされているとは思うもののエヴァンス時代のオブジェクト指向の実装方法がベースだと感じました。
また個人的には、Domain Modeling Made Functionalで紹介されていたような、型によるドメイン知識の表現の方が堅牢でシンプルな実装になると感じています。
第3部 ドメイン駆動設計の実践
第3部では、ビジネスの変化や組織の変化に伴うアプリケーションの変更やドメイン知識を獲得するためのワークショップであるイベントストーミング、既存の大きな泥団子になってしまったアプリケーションの設計変更について述べられています。
この部分はこの書籍の特徴的な部分で、DDDを実践する際に直面する問題に対して、具体的な解決策が提示されているため、非常に有益だと感じました。
また、DDDを実践しないとしても、類似の問題に直面した際にも参考になる内容が多く含まれていると感じました。
イベントストーミングについては、本書に限らず、いくつかのDDDの書籍で取り上げられていますが、本書はその中でも丁寧に解説されていると思います。
その中でも特に印象に残ったのは
「中核から補完へ」で述べられている、「（その）複雑さが事業収益に貢献しない場合（中略）複雑さを取り除く」
という部分です。
複雑さはそれ自体がコストになりうるため、事業収益に貢献しない（かつ変更が一定発生し得る）場合、複雑さ自体を取り除くことが重要であると感じました。
こういった、コードと事業の関係を意識した設計こそがDDDの重要な点であり、それが具体的に示されている部分が非常に有益だと感じました。
第4部 他の方法論や設計技法との関係
第4部ではマイクロサービス、イベント駆動型アーキテクチャ、データメッシュなどの現代的な設計手法とDDDの関係について述べられています。
特にマイクロサービスは書籍「マイクロサービスアーキテクチャ」でもDDDとの深い関連が述べられており、第一版ではマイクロサービスの単位は境界づけられたコンテキストにすべきだと述べられていました。（第2版ではより詳しくDDDとの関連が述べられていますが、まだ私は読み込めていません。）
しかし、本書では「マイクロサービスの単位はサブドメイン（業務領域）にすべきだ。なぜなら境界づけられたコンテキストでは大きすぎるし、集約では小さすぎる」（意訳）ということが述べられていました。
この差分については非常に興味深いと感じましたし、自分が設計する際にも、両方の単位の可能性を考えて設計しようと思いました。
付録
付録Aでは、著者が実際にDDDを実践した際の事例が紹介されています。
「時間がなかったので経営陣がある開発をデータベース管理チームにまかせた」など、恐ろしい事例も含まれており、実践を通して学ばれた教訓を元にこの書籍が書かれていることが伺えます。
また、この付録内の事例を最後まで読んだ上で本書内でも2回引用されている下記の言葉を読むと、事業理解の重要性がより強く感じられます。
『課題の合意なしに解決方針の話をしても無意味である。解決方針の合意なしに実現手段の話をしても無意味である』 エフラット・ゴールドラット・アシュラグ
感想
DDDの事業領域の分析が重要であることと、組織で「ユビキタス言語（同じ言葉）」を使うことの重要性には強く同意します。
ただし、現代は型システムやイミュータビリティを前提とした設計が存在感を増しており、実装をどうするかはDDDではないところに答えを求めた方が良いと感じました。
それでも、DDDに価値がないわけではなく、重要な点のみを受け止めて、実装よりの話は他を参考にするという使い方が良いと思います。
本書は訳語が平易な表現になっていることから、DDDの初学者にとっては受け止めやすいものになりそうです。
自分がチームにDDDの概念を伝えたい時に書籍を勧めるなら本書になると思います。
おまけ DDDに関して思うこと
全てのDDDの書籍で共通しますが、DB設計の話をしていないことに違和感があります。
イベント履歴式ドメインモデルについて、「中核の業務領域」かつ「お金を扱う、分析または監査記録」である場合に適しているとされています。
DB設計においては、中核かどうかに関わらず、お金を扱う、分析または監査記録がある場合には、イベントソーシングを採用するはずです。
アプリケーションレイヤーの話のみでDB設計の話が一切出てこないのは、モデリング・設計論としては不十分だと考えています。
-
ここでいうアクティブレコードは設計パターンです。ORMではありません ↩︎
Discussion