ドメイン駆動設計をはじめよう の商品レビュー

Vlad Khononov(著者),増田亨(訳者),綿引琢磨(訳者)

2026/02/15

DDDについて概要を知っているレベルで読みましたが、すごく面白かったです。

DDDの基本的な概念や概要から、いくつかのアーキテクチャパターンの実例、そして「コアドメインであればこういったアーキテクチャを選択することが推奨されている」といった具体的な内容まで、自分としても気づきが多い本でした。

人にもお勧めしたい良書です。

2026/01/27

システムを「同じ言葉」に基づく「文脈」として捉えることによって、疎結合な設計が可能になる。ドメイン駆動設計を構成する要素の定義から、そのほかの設計思想との関連性まで多角的に学べる。「文脈」から捉えるというアプローチはウィトゲンシュタイン『哲学探究』とも通底する視点を感じられた。

2025/11/16

事業踏み込みでソフトウェア開発、プロジェクトマネジメント、プロダクトマネジメントを担当している技術者にとって救いとなる一冊です。

2025/11/09

ドメイン駆動設計について学びたいと思って読んでみた。
よく分からないドメイン駆動設計の用語を、分かりやすく翻訳してくれて分かりやすかったように思う。
ただ、「ユビキタス言語」を「同じ言葉」と訳すのは結構だいたんだなとは思った。

新しいJavaScriptフレームワークを習得するより、経験したことのない事業分野について理解することのほうが難しいって本当にそうだよなと思う。
今はとある商工組合の業務システムに関わってるのだろうけど、やっぱり業界特有の仕組みとかあってなかなか理解がおいつかない。

モデルが抽象化というのは、確かにそうだよなと思った。読書サービスのユーザー情報に身長や体重の入力は必要ないけど、健康管理サービスなら必要ということはあるだろうしね。
そういう意味では、同じ言葉のようであっても、業界によって意味が異なったりするのだろうなと思う。

それにしても、同じ言葉を扱う点については、非英語圏だとハードル高いよなと思う。自分は、同じ言葉というのならいっそのことソースコードは日本語のローマ字でやったほうがいいのではないかと思って最近はそうすることもあったのだけど、この本によると「クラス名は英単語を使い、ドキュメンテーションコメントで日本語名を併記して対応づける、などが考えられます」と書いてあって、やっぱりそのほうがいいのかななんて思ったりした。

イベント履歴式ドメインモデルという概念は初めて知った。ようは履歴で管理するということなのだろうけど、これって具体的にはどうデータを保持したらいいんだろう？　　　　RDBでもいけるのか？

なお、ドメイン駆動設計が大きな効果をもたらすのは、すでに稼働しているソフトウェアに取り組む場合らしい。そうだったのか…。新規開発ならともかく、既存システムをドメイン駆動設計で書き換えるってかなり大変なイメージがあるのだけど…。

「課題の合意なしに解決方法の話をしても無意味である。解決方針の合意なしに実現手段の話をしても無意味である。」という言葉は、本当そうだよなと思う。今の仕事も、課題の合意なしで、実現手段を考えてる気がしてちょっと怖かったりする…。

CQRS(コマンド・クエリ責任分離)というのはよく聞くけど、いまいちよく分かってない部分もあるので今後勉強していきたいと思う。

2025/09/06

ドメイン駆動設計を体系的にバランスよく学ぶことができる。全体の構成もわかりやすい。

第Ⅰ部 設計の基本方針
第Ⅱ部 実装方法の選択
第Ⅲ部 ドメイン駆動設計の実践
第Ⅳ部 他の方法論や設計技法との関係

第Ⅰ部にはドメイン駆動設計のエッセンスとなる考え方が含まれている。

> 事業課題と要求事項の背景を理解しないまま解発したソフトウェアは、要求事項をソースコードに「翻訳」したにすぎません。（2.2 知識の発見）

> 同じ言葉は業務で使う言葉です。この点はきわめて重要です。同じ言葉に含まれるのは業務用語だけです。技術用語を含めてはいけません。シングルトンやファクトリーパターンが何であるかを業務エキスパートに教えようとしないでください。（2.5 業務で使う言葉）

> 「あらゆるモデルは間違っている。しかし役に立つモデルはある」。モデルは抽象化です。抽象化とは、複雑さをうまく扱うために、課題解決には必要としない詳細を取り除き、課題解決に必要な部分を抜き出す活動です。（2.6 事業活動のモデル）

> 同じ言葉を育てることは、理屈の上では単純でわかりやすい取り組みです。しかし現実はそうではありません。業務知識を習得するただ一つの確実な方法は、業務エキスパートとの会話です。（2.6 事業活動のモデル）

> 業務領域は「発見」であり、区切られた文脈は「設計」です。（3.3 区切られた文脈と業務領域の関係）

第Ⅱ部以降では、とくに区切られた文脈によって表現された、事業を構成する3つの業務領域（中核、補完、一般）の時間変化に対応するための考え方がよく表現されている。現実に寄り添った記述も多い。

> 「価値を生み出すソフトウェア設計には業務知識が不可欠である」というのがドメイン駆動設計の中核にある信念です。ソフトウェア開発でもっとも難しい取り組みの一つが、業務知識の習得です。特に、中核の業務領域を理解することは大きな挑戦です。（11.5 業務知識）

> ドメイン駆動設計の技法を使って、事業活動を深く理解し、業務知識を共有し、設計の意思決定を行うための考え方とやり方を説明してきました。この知識を実際のソフトウェア開発に活かせたら、どんなに楽しいか想像してみてください。...残念ながら、これは夢物語です。目を覚ましましょう。（13章 現実世界のドメイン駆動設計）

具体的な実装の解説もあり、これらも参考になる。

2025/08/01

これまで色々な「ドメイン駆動設計」に関わる本を読んできたが、まさに入門書として強くお勧めしたい本です。

「ドメイン駆動設計」という説明の前の「中核の業務領域」という分類を行う背景だったり、ValueObject、Enitiry、集約、サービスの違いについても、説明をされており良かったです。

もし、ドメイン駆動設計で開発を行う際には、ここの本に書いてある事を思い出して、反復して理解していくのだと思いました。

お勧めしたいです

2025/02/26

DDDの説明が体系的にまとめられており、エヴァンスの本やIDDD本よりも読みやすかった
ただ、同じ言葉が大事だと言っているのにこの本だけ他のDDD本や記事と訳が違う単語があるのはどうなんだろうとは思った
とはいえ内容はわかりやすい。付録Aと同じ轍をそのまま自分が踏みそうな気がしてならない

2024/12/28

ドメイン駆動設計というと値オブジェクトのような戦術的設計に関して聞いたことある程度であったが、どちらかというとコーディングやモデリングの話だと思っていたので学習の優先度を落としていた。

本書を読むとそれはドメイン駆動設計の一部しか見えていなかったのだと痛感した。事業領域、業務領域の分析や、業務領域の分類といった戦略的設計についてはこれこそ自分と自分のプロジェクトに欠けている考えだと感じた。

また、ドメイン駆動設計は難解であると巷の評判でもあったことも敬遠していた理由の一つであったが、本書は説明が平易で非常にわかりやすかった。本のタイトル通り、ドメイン駆動設計の入門書として最適な一冊である。

2024/11/05

ドメイン駆動設計について分かりやすく説明されたとてもいい本。
ただし用語の翻訳について、個人的にはエヴァンス本やIDDDなどで使われている（元の）用語を使った方が良い気がした。

同じ言葉→ユビキタス言語
区切られた文脈→境界付けられたコンテキスト
業務～→ドメイン～

（元の）用語は、ある程度浸透してきていると感じるし、DDDの文脈の用語であることが分かるから。「同じ言葉」や「業務～」はDDD以外の文脈でも使われる言葉だし、埋もれてしまって気付かなかったり、注意をひかなかったりということがありそう、というのが個人的に思ったこと。

でも良い本であることは間違いない。