エリック・エヴァンスのドメイン駆動設計 電子書籍(牧野 祐子 牧野 祐子 今関 剛 今関 剛 今関 剛 和智 右桂 和智 右桂 Eric Evans)|翔泳社の本
  1. ホーム >
  2. 電子書籍 >
  3. エリック・エヴァンスのドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計

翻訳
原著
監修
翻訳
原著
翻訳
原著

形式:
電子書籍
発売日:
ISBN:
9784798126708
価格:
5,720(本体5,200円+税10%)
カテゴリ:
開発管理
キーワード:
#開発環境,#開発手法,#プログラミング,#システム運用
電子書籍

ドメイン駆動設計の定番書 問題解決にフォーカスした設計パターン

「この本は、思慮深いソフトウェア開発者全員の必携書である。」
---Kent Beck 氏推薦

「Eric が見事にとらえたのは、熟練のオブジェクト設計者が常々用いてきた設計プロセスの
一部でありながら、グループとして見ると、この業界の他の人々へうまく伝えられずにいたものだ。
これまで我々は、この知識を断片的には提供してきた。
しかし、ドメインロジックを構築するための原理をまとめ上げ、体系化したことはなかった。
本書は重要である。」
---『Enterprise Java Programming with IBM WebSphere』の著者 Kyle Blown氏 推薦

ソフトウェア開発コミュニティでは、ドメインモデリングがソフトウェア設計の中心であることが広く認められてきています。ドメインモデルを通して、ソフトウェア開発者は豊富な機能を表現し、それをユーザの要求に本当の意味で応えるソフトウェアの実装に移すことができます。

しかし、明らかに重要であるにもかかわらず、効果的なドメインモデリングをどのようにソフトウェア開発プロセスに組み入れるかを説明する、実用的なリソースはほとんど存在しませんでした。ドメイン駆動設計はこの要求に応えるものです。これは具体的な技術についての本ではなく、読者にドメイン駆動設計への体系的なアプローチを提示するものです。

設計のベストプラクティスの応用的なセット、経験に基づくテクニック、さらに、複雑なドメインに直面するソフトウェアプロジェクトにおける開発を容易にする基本原則を紹介する一冊です。

【原書タイトル】Domain-Driven Design: Tackling Complexity in the Heart of Software

第1部 ドメインモデルを機能させる

   ドメイン駆動設計におけるモデルの有用性
   ソフトウェアの核心

第1章 知識をかみ砕く
   効果的なモデリングの要素
   知識のかみ砕き
   継続的学習
   知識豊富な設計
      例1.1——隠された概念を引き出す
   深いモデル

第2章 コミュニケーションと言語の使い方
   ユビキタス言語(UBIQUITOUS LANGUAGE)
      例2.1——貨物輸送プログラムを完成させる
   声に出してモデリングする
   1つのチームに1つの言語
   ドキュメントと図
      書かれた設計ドキュメント
      実行可能な基盤
   説明のためのモデル
      例2.2——輸送業務と経路

第3章 モデルと実装を結びつける
   モデル駆動設計(MODEL-DRIVEN DESIGN)
   モデリングパラダイムとツールによるサポート
      例3.1——手続き型からモデル駆動へ
   骨格を見せる:なぜモデルがユーザにとって重要なのか?
   実践的モデラ(HANDS ON MODELERS)

第2部 モデル駆動設計の構成要素

第4章 ドメインを隔離する
   レイヤ化アーキテクチャ(LAYERED ARCHITECTURE)
      例4.1——オンラインバンキングの機能をレイヤに分割する
      レイヤを関係づける
      アーキテクチャフレームワーク
   ドメイン層はモデルが息づく場所
   利口なUI「アンチパターン」(SMART UI メANTI-PATTERNモ)
   その他の隔離

第5章 ソフトウェアで表現されたモデル
   関連
      例5.1——証券取引口座における関連
   エンティティ(ENTITIES)(別名 参照オブジェクト(REFERENCE OBJECTS))
      エンティティをモデル化する
      同一性のための操作を設計する
   値オブジェクト(VALUE OBJECTS)
      値オブジェクトを設計する
      例5.2——値オブジェクトを使ってデータベースをチューニングする
      値オブジェクトを含む関連を設計する
   サービス(SERVICES)
      サービスと隔離されたドメイン層
      粒度
      サービスへのアクセス
   モジュール(MODULES)(別名 パッケージ(PACKAGES))
      アジャイルモジュール
      例5.3——Javaにおけるパッケージのコーディング規約
      インフラストラクチャ駆動パッケージングの落とし穴
   モデリングパラダイム
      なぜオブジェクトパラダイムが主流なのか?
      オブジェクトの世界におけるオブジェクトではないもの
      パラダイムを混在させる際にはモデル駆動設計に忠実であること

第6章 ドメインオブジェクトのライフサイクル
   集約(AGGREGATES)
      例6.1——購入注文の整合性
   ファクトリ(FACTORIES)
      ファクトリとその場所を選択する
      コンストラクタがあればよい場合
      インタフェースを設計する
      不変条件のロジックはどこへ置くべきか?
      エンティティファクトリ対値オブジェクトファクトリ
      格納したオブジェクトを再構成する
   リポジトリ(REPOSITORIES)
      リポジトリに対して問い合わせる
      クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない
      リポジトリを実装する
      フレームワークの範囲内で作業する
      ファクトリとの関係
   関係データベースに合わせてオブジェクトを設計する

第7章 言語を使用する:応用例
   貨物輸送システムを導入する
   ドメインを隔離する:アプリケーションの導入
   エンティティと値オブジェクトを区別する
      役割とその他の属性
   輸送ドメインの関連を設計する
   集約の境界
   リポジトリを選択する
   シナリオをウォークスルーする
      サンプルアプリケーションの機能:貨物の荷出し地を変更する
      サンプルアプリケーションの機能:リピータへの対応
   オブジェクトの生成
      貨物用のファクトリとコンストラクタ
      荷役イベントを追加する
   リファクタリングのために立ち止まる:貨物集約についてのもう1つの設計
   輸送モデルにおけるモジュール
   新機能を導入する:配分チェック
      2つのシステムを接続する
      モデルを強化する:ビジネスのセグメント化
      パフォーマンスチューニング
   最後に

第3部 より深い洞察へ向かうリファクタリング

   リファクタリングのレベル
   深いモデル
   深いモデル/しなやかな設計
   発見のプロセス

第8章 ブレイクスルー
   ブレイクスルーの話
      悪くないモデルなのだが…
      ブレイクスルー
      さらに深いモデル
      冷静な意思決定
      結末
   好機
   基本への集中
   エピローグ:新しい洞察の連鎖

第9章 暗黙的な概念を明示的にする
   概念を掘り出す
      言葉に耳を傾ける
      例9.1——輸送モデルに欠けている概念を聞き分ける
      ぎこちなさを精査する
      例9.2——利息を得る 難しい方法
      矛盾について熟考する
      文献を読む
      例9.3——利息を得る 文献を用いた場合
      何度でも挑戦すること
   それほど明白でない概念をモデル化する方法
      明示的な制約
      例9.4——再考:オーバーブッキングポリシー
      ドメインオブジェクトとしてのプロセス
   仕様(SPECIFICATION)
      仕様の適用と実装
      例9.5——化学製品倉庫での格納
      例9.6——倉庫内格納サービスの、実際に動作するプロトタイプ

第10章 しなやかな設計
   意図の明白なインタフェース(INTENTION-REVEALING INTERFACES)
      例10.1——リファクタリング:塗料混合アプリケーション
   副作用のない関数(SIDE-EFFECT-FREE-FUNCTIONS)
      例10.2——リファクタリング:塗料混合アプリケーション再考
   表明(ASSERTIONS)
      例10.3——塗料の混合に戻る
   概念の輪郭(CONCEPTUAL CONTOURS)
      例10.4——発生の輪郭
   独立したクラス(STANDALONE CLASSES)
   閉じた操作(CLOSURE OF OPERATIONS)
      例10.5——コレクションから選択する
   宣言的な設計
      ドメイン特化言語
   設計の宣言的スタイル
      宣言的スタイルで仕様を拡張する
      例10.6——コンポジット仕様を実装する他の方法
   攻める角度
      サブドメインを切り取る
      可能な場合には、確立された形式主義を活用する
      例10.7——パターンを統合する:シェア算

第11章 アナリシスパターンを適用する
      例11.1——利息を得る 勘定を用いた場合
      例11.1(続き)——夜間バッチについての洞察
      アナリシスパターンは活用すべき知識である

第12章 デザインパターンをモデルに関係づける
   ストラテジー(STRATEGY)(別名 ポリシー(POLICY))
      例12.1——経路検索ポリシー
   コンポジット(COMPOSITE)
      例12.2——経路で構成された輸送経路
   なぜ、フライウェイトではないのか?

第13章 より深い洞察へ向かうリファクタリング
   開始
   探究チーム
   先達の技
   開発者のための設計
   タイミング
   好機となる危機

第4部 戦略的設計

第14章 モデルの整合性を維持する
   境界づけられたコンテキスト(BOUNDED CONTEXT)
      例14.1——予約コンテキスト
      境界づけられたコンテキスト内での分派を認識する
   継続的な統合(CONTINUOUS INTEGRATION)
   コンテキストマップ(CONTEXT MAP)
      例14.2——輸送アプリケーションにおける2つのコンテキスト
      コンテキストの境界で行うテスト
      コンテキストマップを構成してドキュメント化する
   境界づけられたコンテキスト間の関係
   共有カーネル(SHARED KARNEL)
   顧客/供給者の開発チーム(CUSTOMER/SUPPLIER DEVELOPMENT TEAMS)
      例14.3——収益分析と予約
   順応者(CONFORMIST)
   腐敗防止層(ANTICORRUPTION LAYER)
      腐敗防止層のインタフェースを設計する
      腐敗防止層を実装する
      例14.4——レガシー予約アプリケーション
      訓話
   別々の道(SEPARATE WAYS)
      例14.5——保険プロジェクトの縮小化
   公開ホストサービス(OPEN HOST SERVICE)
   公表された言語(PUBLISHED LANGUAGE)
      例14.6——化学のための公表された言語
   象のモデルを統一する
      モデルコンテキスト戦略を選択する
      チームでの意思決定と、より上層での意思決定
      コンテキストに自らの身を置く
      境界を変換する
      変更できないものを受け入れる:外部システムの輪郭を描く
      外部システムとの関係
      設計中のシステム
      別のモデルで特殊な要求を満たす
      デプロイ
      トレードオフ
      すでにプロジェクトが進行中の場合
   変換
      コンテキストをマージする:別々の道 → 共有カーネル
      コンテキストをマージする:共有カーネル → 継続的な統合
      レガシーシステムを段階的に廃止する
      公開ホストサービス → 公表された言語

第15章 蒸留
   コアドメイン(CORE DOMAIN)
      コアを選択する
      誰がこの作業をやるのか?
   蒸留の拡大
   汎用サブドメイン(GENERIC SUBDOMAINS)
      例15.1——2つのタイムゾーンの物語
      汎用とは再利用可能という意味ではない
      プロジェクトのリスク管理
   ドメインビジョン声明文(DOMAIN VISION STATEMENT)
   強調されたコア(HIGHLIGHTED CORE)
      蒸留ドキュメント
      コアにフラグを立てる
      プロセスツールとしての蒸留ドキュメント
   凝集されたメカニズム(COHESIVE MECHANISMS)
      例15.2——組織図におけるメカニズム
      汎用サブドメイン対凝集されたメカニズム
      メカニズムがコアドメインの一部である場合
      例15.3——一巡:組織図がメカニズムを再び吸収する
   蒸留して宣言的スタイルにする
   隔離されたコア(SEGREGATED CORE)
      隔離されたコアを作成するコスト
      チームの意思決定を進化させる
      例15.4——貨物輸送モデルのコアを隔離する
   抽象化されたコア(ABSTRACT CORE)
   深いモデルの蒸留
   リファクタリングの対象を選ぶ

第16章 大規模な構造
   進化する秩序(EVOLVING ORDER)
   システムのメタファ(SYSTEM METAPHOR)
      「素朴なメタファ」とそれを必要としない理由
   責務のレイヤ(RESPONSIBILITY LAYERS)
      例16.1——深く掘り下げる:輸送システムをレイヤ化する
      適切なレイヤを選択する
   知識レベル(KNOWLEDGE LEVEL)
      例16.2——従業員の給料と年金(1)
      例16.3——従業員の給料と年金(2)知識レベル
   着脱可能コンポーネントのフレームワーク(PLUGGABLE COMPONENT FRAMEWORK)
      例16.4——SEMATECH CIMフレームワーク
   構造による制約をどの程度厳しくするべきか?
   ふさわしい構造へのリファクタリング
      ミニマリズム
      コミュニケーションと自己規律
      再構成によってしなやかな設計がもたらされる
      蒸留によって負荷が軽減される

第17章 戦略をまとめ上げる
   大規模な構造と境界づけられたコンテキストを組み合わせる
   大規模な構造と蒸留を組み合わせる
   まず評価する
   誰が戦略を策定するのか?
      アプリケーション開発から現れる構造
      顧客に焦点を合わせたアーキテクチャチーム
   戦略的設計上の意思決定を行うために欠かせない6つのこと
      同じことが技術的なフレームワークにも当てはまる
      マスタプランに注意すること

結論

   エピローグ
   展望
 

付録 用語解説 参考文献 索引
本書は付属データの提供はございません。

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影(表紙画像)をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影(表紙画像)以外のご利用については、こちらからお問い合わせください。

追加情報はありません。
この商品の「よくある質問」はありません。

ご購入いただいた書籍の種類を選択してください。

書籍の刷数を選択してください。

刷数は奥付(書籍の最終ページ)に記載されています。

現在表示されている正誤表の対象書籍

書籍の種類:

書籍の刷数:

本書に誤りまたは不十分な記述がありました。下記のとおり訂正し、お詫び申し上げます。

対象の書籍は正誤表がありません。

最終更新日:2022年09月08日
発生刷 ページ数 書籍改訂刷 電子書籍訂正 内容 登録日
1刷 028
6行目、11行目
2刷
6行目・・・あとは、それまでに通関地点を一切通過していなくても 11行目・・・すで通過した通関地点が偶然正しかった場合には、
6行目・・・とにかく、それまでに通関地点を一切入力していなくても、 11行目・・・過去入力した通関地点が偶然正しかった場合には、

※リフローEPUBの場合、第2章の図2.1の下にあるユーザと開発者の対話のうち、2つ目と3つ目のユーザの発言が該当箇所になります。
2011.04.26
1刷 029
下から6行目
2刷
すで通過した通関地点が偶然正しかった場合には、
過去入力した通関地点が偶然正しかった場合には、

※リフローEPUBの場合、第2章の図2.2の下にあるユーザと開発者の対話のうち、3つ目のユーザの発言が該当箇所になります。
2011.04.26
1刷 084
SQL文の下から4行目
4刷
"BROKERAGE_ACCOUNT='" + accountNumber + "'";
"ACCOUNT_NUMBER='" + accountNumber + "'";

※リフローEPUBの場合、第5章の見出し「例5.1 ――証券取引口座における関連」の2つ目のコード例が該当箇所になります。
2012.10.17
1刷 086
SQL文の下から6行目
4刷
"WHERE BROKERAGE_ACCOUNT='" + accountNumber + "'";
"WHERE ACCOUNT_NUMBER='" + accountNumber + "'";

※リフローEPUBの場合、第5章の見出し「例5.1 ――証券取引口座における関連」の図5.4の後にある、2つ目のコード例が該当箇所になります。
2012.10.17
1刷 119
16行目
3刷
強固なユビキタス言語である。これはある2つの環境で一貫した
強固なユビキタス言語である。これはある2つの環境で一貫した

※リフローEPUBの場合、第5章の「モデリングパラダイム」の小見出し「パラダイムを混在させる際にはモデル駆動設計に忠実であること」の5つ目の段落が該当箇所になります。
2011.07.20
1刷 126
第6章 図6.3
3刷
左下のクラス名・・・状態 中央下のクラス「タイヤ」の制約・・・{期間 = sum(位置.期間)}
左下のクラス名・・・位置 中央下のクラス「タイヤ」の制約・・・{走行距離 = sum(位置.走行距離)}
2011.06.27
1刷 166
「エンティティと値オブジェクトを区別する」の「顧客(Customer)」上から2行目

(画像クリックで拡大)

(画像クリックで拡大)

赤線部分「エンティティ」はパターン名のエンティティではないため、正しいフォントはゴシック体ではなく明朝体です。

※リフローEPUBの場合、第7章の見出し「エンティティと値オブジェクトを区別する」にある小見出し「顧客(Customer)」の最初の段落が該当箇所になります。
2021.04.16
1刷 177
本文13行目、下から5行目
2刷
13行目・・・荷役イベントが持つ配送記録のコレクションを 下から5行目・・・配達記録に対して
13行目・・・配送記録が持つ荷役イベントのコレクションを 下から5行目・・・配送記録に対して

※リフローEPUBの場合、図7.5の後にある見出し「リファクタリングのために立ち止まる:貨物集約についてのもう1つの設計」の3つ目の段落、および4つ目の段落が該当箇所になります。
2011.04.18
1刷 190
(ページ中ほど)箇条書きの1.
2刷
苦労して実現する価値がある
苦労して実現する価値がある。

※リフローEPUBの場合、第3部の冒頭にある番号付き箇条書きの「1.」が該当箇所になります。
2011.05.12
1刷 215
図9.6

(画像クリックで拡大)

(画像クリックで拡大)

「利息計算」→「利息の発生」
2022.09.08
1刷 221
「それほど明白でない概念をモデル化する方法」の2行目
2刷
「発生」のように非常に抽象的なものも含て
「発生」のように非常に抽象的なものも含めて

※リフローEPUBの場合、第9章の図9.9の後にある見出し「それほど明白でない概念をモデル化する方法」の最初の段落該当箇所になります。
2011.05.23
1刷 279
訳注
2刷
ジェネリスク
ジェネリクス

※リフローEPUBの場合、第10章の末尾に記載されている「訳注」が該当箇所になります。
2011.05.23
1刷 280
最終行
3刷
実装方法が多くのだ。
実装する方法は数多くあるのだ。

※リフローEPUBの場合、第10章の図10.14の直前にある段落が該当箇所になります。
2011.06.27
1刷 287
下から10行目
2刷
設計全体に対して、一度に取り組むことはできない。一度に切り出すこと。
設計全体に対して、一度に取り組むことはできない。一部を切り出すこと。

※リフローEPUBの場合、第10章の「攻める角度」の小見出し「サブドメインを切り取る」の最初の段落が該当箇所になります。
2011.04.09
1刷 288
第10章 「例10.7 ――パターンを統合する:シェア算」の1行目
4刷
第8章では、シンジケートローンシステムを構築するプロジェクトで起き、
第8章では、シンジケートローンシステムを構築するプロジェクトで起き
2012.09.28
1刷 288
7行目
2刷
これらの中には何世紀にもわたって改良され蒸留されてきたもある。
これらの中には何世紀にもわたって改良され蒸留されてきたものもある。

※リフローEPUBの場合、第10章の「攻める角度」の小見出し「可能な場合には、確立された形式主義を活用する」の最初の段落が該当箇所になります。
2011.04.09
1刷 342
第14章 図14.1上部
2刷
モデルの統一を 保つのに使用する
モデルの統一を 保つのに使用する

余分な「で」を削除しました
2011.04.09
1刷 356
第14章 図14.3
2刷
ネットワーク横断サービス
ネットワーク走査サービス
2011.05.12
1刷 363
柱と見出し
4刷
共有カーネル(SHARED KARNEL)
共有カーネル(SHARED KERNEL)

※リフローEPUBの場合、柱はありません。
2019.11.08
1刷 364
1行目
2刷
少ないコストでほ利益のとんどを得られる。
少ないコストで利益のほとんどを得られる。

※リフローEPUBの場合、第14章の「境界づけられたコンテキスト間の関係」の図「共有カーネル(SHARED KERNEL)」の後にある3つ目の段落が該当箇所になります。
2011.05.09
1刷 402
箇条書き内
6. 現実的でないと判明するかもしれないが、レガシーシステムで現在使用されていないモジュールを稼働させることを考えること。
6. 現実的でないと判明するかもしれないが、レガシーシステムで現在使用されていないモジュールを除外することを考えること。
2022.02.24
1刷 411
第15章の小見出し「誰がこの作業をやるのか?」の2段落目
2刷
長期にわたって参画し、~(中略)~ 1人以上をうまく協力させるチーム
長期にわたって参画していて~(中略)~ 1人以上がうまく協力しあえるようなチーム
2011.05.23
1刷 434
本文18行目
2刷
凝集されたサブドメイン
(※パターン名を示す書体になっていますが、クラスではなく本文です)

ゴシック体から明朝体に修正しました。

※リフローEPUBの場合、第15章の小見出し「隔離されたコア(SEGREGATED CORE)」の4つ目の段落(「これは、」で始まる段落)が該当箇所になります。
2011.04.26
1刷 482
ページ中ほど
2刷
内部設計を
内部設計を

※リフローEPUBの場合、第16章の「着脱可能コンポーネントのフレームワーク(PLUGGABLE COMPONENT FRAMEWORK)」の3つ目の段落が該当箇所になります。
2011.05.23
1刷 490
8~9行目
10刷
その部分を改良しなくてもよくなくなる。
その部分を改良しなくてもよくなる。

※リフローEPUBの場合、第16章の最後の見出し「蒸留によって負荷が軽減される」の2つ目の段落が該当箇所になります。
2018.02.01
1刷 500
下から4行目末尾~
2刷
チームメンバに、~(中略)~ チームの間を実際に意見聴取のため回った。
メンバが~(中略)~ チームの間を回って意見を聞いていた。

※リフローEPUBの場合、第17章の「戦略的設計上の意思決定を行うために欠かせない6つのこと」の小見出し「意思決定プロセスはフィードバックを吸収しなければならない。」の3つ目の段落が該当箇所になります。
2011.05.23
1刷 539
訳者紹介「和智右桂」
11刷
http://d.hatena.ne.jp/digitalsoul/
https://digitalsoul.hatenadiary.org/
2020.05.21
1刷 xxx
目次 第4部「戦略的設計」下から8行目
4刷
共有カーネル(SHARED KARNEL)
共有カーネル(SHARED KERNEL)
2019.11.08
1刷 裏見返し
図の上部
2刷
隔離されたコア p.XXX
隔離されたコア p.434

※リフローEPUBの場合、巻末に掲載されている図が該当箇所になります。「隔離されたコア」については第15章の「隔離されたコア(SEGREGATED CORE)」をご参照ください。
2011.04.26

感想・レビュー

さん

2020-05-07

ドメイン駆動設計の前提となっている「ソフトウェアにとって一番大事なことは、どんな技術を使うかではなく、何を作ろうとしているのか(≒ドメイン)である」という考え方には非常に共感できた。(技術にしか興味がないプログラマを批判的に取り上げていたのも面白い)また実際に紹介されている手法を自分のプロジェクトに導入し、効果を実感することもできたので、名著と言われているのは納得できるが…

さん

2021-07-30

エンジニアキャリアをどのようにスタートしたかによって相当見方が変わる本だと思いました。Railsのようにレールがはっきりした世界の目線で読むと、別のレールのパターンを見てるだけのように見えるなと。しかしJavaScriptでノーレールの世界のものとして見ると、DDDは強力な手法に見えると思いました。ただ、現在はこういった議論を経た上でフレームワークのサポートや設計の当たり前基準があがっているので原論を読む感じだと思いました。

ilma さん

2011-09-10

★★★★☆ システム化する業務の本質をモデル化し、モデルを継続して極めていく、再利用すべきはコードでなく設計であるという考え方は次元が高いと思いました。耳慣れない言葉も多いのですが、設計例がかなり多いので、時間を掛ければ理解できると思います。(米国では)良い設計のソフトであれば、たとえ会社が潰れてもソフトと開発者を引き取る企業があるという後書きも興味深いです。個人的には日米の開発者に差はないと信じていますが、良い設計が稼ぎにつながりやすい風土が米国の開発者の元気に繋がっているような気がします。