読書メモ。2025年69冊目。
『ドメイン駆動設計をはじめよう』を読んでの感想となります。（2025/11/27記載）
本の概要
ドメイン駆動設計はエリック・エヴァンスにより提唱されたソフトウェア設計の手法です。対象とする事業活動（ドメイン）とその課題の観点から、より良いソフトウェアを構築するために関係者が協力する方法を提供します。本書は4部構成になっており、第Ⅰ部「設計の基本方針」では、ソフトウェアの設計方針を大きな視点から決めるための考え方とやり方を取り上げます。第Ⅱ部「実装方法の選択」ではソースコードに焦点を合わせ、業務ロジックをどう実装するかの選択肢を学びます。第Ⅲ部「ドメイン駆動設計の実践」では、ソフトウェア開発の現場にドメイン駆動設計を実践的に取り入れるための方法を紹介します。第Ⅳ部「他の方法論や設計技法との関係」では、ドメイン駆動設計とそれ以外の方法論や設計技法との関係を検討します。最新の技術トレンドを取り入れながら、ドメイン駆動設計の基本概念と実践方法をわかりやすく解説します。
引用：
動機
- 10年前からDDDを学びたいと思いつつ機会を見失ってきた。
- アーキテクチャConferenceに合わせ積んでいた一冊を読む機運が高まった。
- この機を逃すときっといつまでも学べないとドメイン駆動設計はじめました。
本書からの学び
私がドメイン駆動設計（DDD）と出会ったのは、10年前に参加した勉強会でした。
特にDDDに対する知識無く、設計について知識を深めたいという想いから勉強会に参加した記憶があります。
以来、増田亨さんのTwitterをフォローし、DDDに関する知識のキャッチアップを進めたものの、本腰を入れた学習をすることなく10年という時が経ってしまいました。
増田亨さんが何かの勉強会で『エリック・エヴァンスのドメイン駆動設計』について、「難解なので分からないことが多いと思う」「ただ、分からないことが分かることだけでも重要」というようなことを仰っていたことを記憶しています。
今回、それよりも理解にやさしいと評判の『ドメイン駆動設計をはじめよう』を読んで、今まで得てきた断片的な知識を整理できたうえで、
やはりソフトウェア開発において実践していくレベルでは、まだまだ自分の理解が足りていないとも思いました。
そのためには、本書を読み返したり実践に適用していくことが重要と思っています。
事業活動を業務活動に分解し、その領域を切り分ける話や、DDDの基礎知識について、再度学ぶことができたことだけでなく、
マイクロサービスやイベント駆動型アーキテクチャとの関連性を学ぶことができたことも嬉しかったです。
特にマイクロサービスについては、DDDよりももっと表層的な知識にとどまり、一体どのレベルまでマイクロなのかが気になっていたため、DDDとの整合によって理解を深めることができました。
書籍全体を通して、ドメイン駆動設計は改めて難解であり、難解であるからこそ中核の業務領域に適用すべきと学ぶことができました。
この本を読み終えた上で、先日のアーキテクチャConferenceでのヴラッド・ホノノフさんの登壇を思い出すと理解が深まります。
10年前に学習をはじめていれば今はもっと、と思う部分もありますが、今からでも遅くないと思い、これからも理解を深めていきます。
忘れたくないメモ
ソフトウェア開発は学びのプロセス
アルベルト・ブランドリーニが言っているとおりです。ソフトウェア開発は学びのプロセスです。動くコードは学びの副産物です。ソフトウェア開発プロジェクトが成功するかどうかは、業務エキスパートとソフトウェア技術者が知識を効果的に共有できるかどうかで決まります。よいソフトウェアを作るためには、解決すべき課題の理解が必要です。
ソフトウェア開発は解決すべき課題に対する学びのプロセス。
コードは副産物であって、課題解決が目的。
業務知識は伝言ゲームの途中で誤って伝わる
こういうソフトウェア開発のやり方は伝言ゲームです。つまり、業務知識は伝言ゲームの途中で誤って伝わります。そういう誤った情報をもとにして開発すれば誤ったソフトウェアが生まれます。あるいは本来の課題とはまったく別の課題を解決するソフトウェアが生まれます。どちらにしても結果は一つです。つまり、ソフトウェア開発プロジェクトの失敗です。
プロダクトオーナーと開発者との関係だけでも本来の意図を伝えきれず誤って開発が進むことがあると思っています。
だからこそ、サイロをなくし、作るものの目的をすりあわせることが重要だと考えています。
事業の役に立つソフトウェア
ソフトウェア開発者が事業領域を技術的な観点だけで見ているとどうなるでしょうか。そういう開発者は業務ロジックやその機能が必要な理由を正しく理解できません。つまり事業の役に立つソフトウェアを生み出すことができません。
作ることは手段であり、課題解決による事業成長をどうエンジニアリングで実現していくかが重要。
ソースコードが同じ言葉を話す
もっとも重要なことは、値オブジェクトが業務の概念を表現することです。つまり、値オブジェクトを使うことで、ソースコードが同じ言葉を話します。
コードに意図を持たせることは、コードが業務を実現すること。
区切られた文脈の境界を適切に設計する
複数の区切られた文脈にまたがる変更はたいへんです。調整に多くの時間と労力が必要です。変更の対象となる複数の区切られた文脈を別々のチームが開発している場合は、特にたいへんです。変更の影響する範囲を特定の区切られた文脈にカプセル化できていないとしたら、区切られた文脈の境界を適切に設計できていない、ということです。
開発組織のありかたとしてどういった形が良いのか考えたい。
