「つくりながら学ぶ！ドメイン駆動設計 実践入門」を読みました。
どうも。Reoです。
「つくりながら学ぶ！ドメイン駆動設計 実践入門」を読み終えたので、感想ブログを書いていこうと思います。
本を読んだきっかけ
本屋で色々と物色している時に、気になって手に取りました。パラパラと中身を見ていると、オニオンアーキテクチャを採用したハンズオンで学べる本であることがわかりました。
少し前に、自分のプロジェクトにオニオンアーキテクチャを取り入れようとしていたこともあり、とても興味が湧き、購入を決めました。
出版日も2026年1月21日と新しい本になります。
本書の構成
Part1〜4 まであり、Chapter は21 まであります。
Part 1 ドメイン駆動設計への招待
Chapter 1 はじめに
Chapter 2 ビジネス課題とドメイン駆動設計
Part 2 ビジネス価値の発見
Chapter 3 戦略的設計
Chapter 4 業務知識の獲得
Chapter 5 ドメインモデルの可視化
Part 3 ドメインモデルの実装
Chapter 6 戦術的設計とコード実装
Chapter 7 アーキテクチャ
Chapter 8 実装の準備
Chapter 9 値オブジェクト
Chapter 10 エンティティ
Chapter 11 集約
Chapter 12 ドメインサービス
Chapter 13 リポジトリ
Chapter 14 アプリケーションサービス
Chapter 15 プレゼンテーション層の実装
Part 4 ビジネス価値を守り続ける
Chapter 16 拡張性とメンテナンス
Chapter 17 中核ビジネスロジックの独立性を守る
Chapter 18 ビジネスロジックを技術実装の詳細から分離する
Chapter 19 イベント駆動アーキテクチャ
Chapter 20 Outboxパターンによる確実なイベント発行
Chapter 21 イベントソーシングという選択肢
一読してみて
とにかく丁寧で、読みやすく、わかりやすかったです。
本書を手に取るまではドメイン駆動設計というものが何か全然わかっておらず、いわゆるプログラミングの設計の本だと思って興味を持ち、手に取りました。「綺麗なコードを書くため」「オニオンアーキテクチャを採用するため」に本書に興味を持ったわけですが、「著者まえがき」の段階でドメイン駆動設計はそうじゃないよと言われてしまいます。
私たちがドメイン駆動設計を学ぶのはなんのためでしょうか。それは、単にきれいなコードを書くためでも、流行のアーキテクチャを採用するためでもありません。他者との差別化の源泉となる「中核ドメイン」を見極め、そこにある複雑なビジネスルールをシステムとして表現し、継続的に磨き上げることでビジネスの競争優位性を生み出し続けるためです。
著者まえがき より
まえがきを読んで、ドメイン駆動設計って全体の考え方のことなのか…！今一番求めていたものかもしれない…！と思い、わくわくしながら読み始めました。
自分は本書を読む前までドメイン駆動設計を、テスト駆動開発だとかの仲間だと思っていました…。
ビジネス価値を発見する戦略的設計
ドメイン駆動設計のはじまりは、アーキテクチャを選ぶことではありませんでした。
まず最初に必要なのが、ビジネスを理解することでした。複雑なビジネスをどう理解し、どうソフトウェアで支えるかを考えること。業務の問題領域であるドメインを理解して、分割するところから始まります。
開発者向けの考え方で、ドメイン駆動設計以外にこのようなことを考えるところから始まる手法って他にあるんですかね？戦術的設計のような話は溢れていますが、戦略的設計も含めた設計手法っていうのはあんまり見たことない気がしています。
戦略的設計のパートでは、オンライン書店を例に、実際にコンテキストマップやドメインモデルをPlantUMLで作成するところからハンズオンで学べます。
オニオンアーキテクチャを使った戦術的設計
戦術的設計の部分も為になりまくりでした。
ドメイン駆動設計の戦術的設計の主要な構成要素をそれぞれハンズオンで実装していきます。
- 値オブジェクト
- エンティティ
- 集約
- ドメインサービス
- リポジトリ
- アプリケーションサービス
- プレゼンテーション層
それぞれについて、概要と実装とテストまでセットで紹介されています。値オブジェクトを使わない場合はどうなるかなど、悪い例とともに紹介されていて、とてもわかりやすかったです。
これらはドメイン駆動設計の構成要素であり、オニオンアーキテクチャというアーキテクチャを利用しているからこの構成要素になったというわけではない、という部分が個人的には大きな気づきでした。
アーキテクチャによって、ユースケースと読んだりインタラクターと読んだり…じゃあこれらの違いって何？と思うことが多かったんですが、構成要素的にはどちらも「アプリケーションサービス」で同じであり、これらの構成要素をどの層に配置して、どこを依存させていいかを決めるのがアーキテクチャなのかなという認識になりました。なのでドメイン駆動設計で他のアーキテクチャを選ぶとしても、大きく要素が変わるわけではないのかな？という理解をしました。（あってるかな…？）
たとえドメイン駆動設計ほど重い設計ではなくとも、ソフトウェアの構成要素を丁寧に分けると、こういう分け方がいいんだろうなぁと思いました。
とはいえ、実際に他の言語に落とし込むのは結構難しそうではあります。頑張って身につけたいところです。
作るのはWebサーバー
Chapter 15 プレゼンテーション層の実装に辿り着いて、ああそうか、バックエンドのサンプルなのかと気づきました。(遅い)
オンライン書店を例にしたハンズオンで、ユーザーがフォームなどから入力して動作するソフトウェアだと思い込んでいました。プレゼンテーション層で外部に公開するのは Web API で、そっかUIないのか…！とちょっとびっくりしました。自分がフロントエンド脳すぎました。
自分が作るものはUIありきのものばかりなので、この後UIを実装するならどうやってアプリケーションサービスと紐づければいいのかが悩ましいですね。その部分がなかなか難しく、何かでもう少し勉強したいところです。
手を動かして学ぶことができる
プロジェクトの環境構築からテストの実行まで、コードは全文紹介されているので、手を動かしながら学ぶことができます。後半の20章と21章はページ数の都合上で本自体には書かれていませんが、GitHub 上に公開されています。
今回は時間の都合上ハンズオンではやらずに、コードを見るだけにとどめておきましたが、もう一周ハンズオンでも読み返したいなと思っています。
後半は非常に難しい
「Part 4 ビジネス価値を守り続ける」からの Chapter はかなり難しく感じました。Chapter 18 までは頑張れましたが、Chapter 19 からのイベント駆動アーキテクチャの話からは、非常に難しいです。
コード自体は、パブリッシャーとサブスクライバーでRx的なことをやっているんだなーと読めはするんですが、概念的なところがとても難しいです。
「イベント駆動アーキテクチャ」だったり「Outboxパターン」だったり「Sagaパターン」だったり「イベントソーシング」だったり…。
本書が悪いわけでは全くないんですが、何にでもアーキテクチャとかパターンって言うのが、本当にややこしいですよね。イベント駆動アーキテクチャとドメイン駆動開発は同じレイヤーの話ではないし、イベント駆動アーキテクチャとクリーンアーキテクチャも同じレイヤーの話ではない。同じ駆動がついていたり、アーキテクチャがついていたりするのに。言葉が広いよ。
あとは、後半の章では特に、疎結合とか非同期処理がいい感じになることで、整合性を合わせることが課題になっていて、難しい問題だなぁと感じました。疎結合にしなければ整合性を合わせることが簡単なのに…という場面において、果たして本当に疎結合であることが正しいのか考えてしまいます。非同期処理はUX観点で非同期である方が良いといえそうですが、疎結合は…バグるよりかは密結合の方がマシなのではと思っちゃいそうです。何が良くて何が悪いのかが非常に難しいです。
感じる溝
本書の感想というより、小言なんですが、デザイナーとエンジニアってかなりの溝がありますよね。
本書を読む前に、モデルベースUIデザイン 構造化UIと情報設計の方法論の本とFigmaではじめるUXデザイン入門を読んでいました。どちらもUIデザインに関する本です。
私は個人開発や小さいチームでの開発が多く、たまにデザインもするソフトウェアエンジニアみたいなもので、最近は色々な本を読んで勉強しています。
モデルベースUIデザインの本、FigmaではじめるUXデザイン入門、ドメイン駆動設計の本、と読み進めて、デザインと開発には大きく溝があるんだろうなぁ…と思ってしまいました。
どちらも何かの問題を解決しようとする向き先は同じであるんだなということは、本書を読んですごく感じました。ドメイン駆動設計は、ソフトウェアの解決したい問題領域(ドメイン)を理解してコードに反映させる設計手法。UIデザインではきっと、それを反映させる場所がコードではなくUIということだと思うんです。
なのにここに非常に溝を感じてしまう。
本書で紹介されている戦略的設計のイベントストーミング(プロジェクト関係者達での協同作業)とその成果物であるコンテキストマップは、エンジニア以外に強いるのは難しいのではないかと思ってしまいました。コンテキストマップは初見で理解するのは難しく、説明されて初めて理解できるものだと感じました。一方、デザイナー側の提案する似たような協同作業(FigmaではじめるUXデザイン入門の課題発見とコンセプト作成など)は、初見でも誰でも参加しやすいですが、そのままコードに落とし込むには情報が足りないように感じます。
これってどうにかならないのかなぁ、と思いながら読んでいました。
実際UIデザインもプログラミングもする立場からすると、どちらもメリット/デメリットがあり、なにかひとつ両者と関係者が理解しやすい手法があればいいのになぁと思ってしまいます。
おわりに
本書を読んで、これまでドメイン駆動設計と出会ってこなかったことを悔いました。もっと早く出会っていたかったです。戦略的設計から、戦術的設計に落とし込んで、ビジネスルールをシステムとして表現すること。読みやすいコード、キレイなコードの根幹は、そういうものかもしれない…。
もちろん戦略的設計と戦術的設計を組み合わせてドメイン駆動設計ではあるのでしょうが、戦略的設計をしていない（ビジネスを理解していない）状態でコードを書き始めるのは、愚かだったなぁと思いました。
アーキテクチャパターンを知り、ただ闇雲にそのパターンに当てはめてコードを書いて、できる気になっていた自分に、早くこの本読んでおけ！と伝えたいです。
より理解を深める為に、ドメイン駆動設計の提唱者であるエリック・エヴァンス氏の「エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)」と本書の監修者である増田さんが翻訳した「ドメイン駆動設計をはじめよう ―ソフトウェアの実装と事業戦略を結びつける実践技法」も読みたいところです。難しいらしいので、本書からの入門で正解だったかも。
つくりながら学ぶ！ ドメイン駆動設計 実践入門、是非読んでみてください。
個人的な話ですが、妊娠中で胎教代わりにと本書を全文音読しました。異常者です。でも音読ってめちゃめちゃいいかもしれないです。おすすめです。
