Base DDD(ドメイン駆動設計）参考文献を巡る旅

Base-DDD 参考文献を巡る旅ver2.0
1
2014.09.21 DDD読書会@大阪 LT大会

はじめに
DDD （ドメイン駆動設計）本に記載されている参考文献には、 DDD本出版前から著名だった書籍が多数含まれています。
私も読んだ事がある本もあったのですが、これら個々で理解していた知識が、DDD本で見事に集約されており、
「成るほど！」と感心する事が多々ありました。
そこで、どのような参考文献が、DDDのどの箇所に、どのように使用されているか調べ、DDD思想の根底に、少しでも触れればと思います。
2

自己紹介
3
●かわべたくや
●Twitter : @kawakawa
●大阪在住
●DDD猛烈勉強中！

参考文献一覧(1/4)
•『オレゴン大学の実験』
•『パタン・ランゲージ：環境設計の手引』
•『J2EE パターン第2 版』
•『ケント・ベックのSmalltalk ベストプラクティス・パターン― シンプル・デザインへの宝石集』
•『XP エクストリーム・プログラミング入門―変化を受け入れる』
•『テスト駆動開発入門』
5
※日本語訳がある場合は、翻訳版を掲載

•『ソフトウェアアーキテクチャ：ソフトウェア開発のためのパターン体系』
•『アジャイルプロジェクト管理』
•“Specifications.” Proceedings of PLoP 97 Conference.
•『Domain-Specific Application Frameworks』
•『アナリシスパターン―再利用可能なオブジェクトモデル』
•『リファクタリング―プログラムの体質改善テクニック』
•『エンタープライズアプリケーションアーキテクチャパターン』
6

•『オブジェクト指向における再利用のためのデザインパターン改訂版』
•“Continuous Learning,” in Extreme Programming Perspectives http://www.industriallogic.com/xp/refactoring
•『実践UML 第3 版―オブジェクト指向分析設計と反復型開発入門』
•『オブジェクト指向入門第2 版原則・コンセプト、方法論・実践』
7

•Abstract 40. Abstract 40. Presented as a poster at the 210th ACS Meeting in Chicago on August 21, 1995. http://www.ch.ic.ac.uk/cml/
•『言語を生みだす本能上巻・下巻』
•『Extreme Programming Perspectives』
•『The Object Constraint Language: Precise Modeling with UML』
•『オブジェクトデザイン』
8

amazon
http://www.amazon.co.jp/dp/4306051285
紹介文（抜粋）
パタン・ランゲージを実践。
マスタープラン型開発思想を否定し、市民参加と漸進的成長によって活動的で健康なコミュニティを再生させるため、オレゴン大学で試みた、建築と計画に対する全く新しいアプローチ。
「コミュニティデザインについて考えるときのヒント」 (山崎亮氏)
オレゴン大学の実験
10

11
DDD本掲載箇所一覧
●第17章戦略をまとめ上げる
「戦略的設計上の意思決定を行うために欠かせない６つのこと」
マスタプランに注意することChristopher Alexander が率いるアーキテクトのグループは、建築と都市計画の分野で段階的成長を提唱した。
何らかの計画プロセスがなければ、
～略～
［これは、定義上］共同体のメンバが自らの共同体の将来の姿にほとんど影響を与えることができないからであり、それは重要な決定のほとんどがすでになされているからだ。『オレゴン大学の実験（The Oregon Experiment）』p.16-28（Alexander 他1975）より
Alexander と彼の仲間が代わりに提唱したのは、段階的成長に関するあらゆる活動に対して、共同体のメンバ全員が適用できる原理の集合である。それによって、状況にうまく適合した「有機的秩序（organic order）」が姿を現すようにしたのだ。

12
残念ながら未読です。しかし、あの絵（顧客が本当に必要だったもの）は有名ですよね。
DDD本読んだ後だと違う感想抱きました。「あっ。これコアドメインなんだ」と。
自分メモ

amazon
都市計画と建築と建設についての新しい理論を示すものであり有機的な環境作りのプロセスを集大成した、いわばバイブルに類例さるべき大著である。 253のパタンと800余の挿図。
( 第21回日本翻訳出版文化賞受賞 )
パタン・ランゲージ：環境設計の手引
13

14
●付録本書におけるパターンの使い方
設計における洞察を共有し、標準化する形式は、Christopher Alexander 率いる建築家グループによって1970年代に紹介された（Alexander 他1977）。
彼らの「パターンランゲージ」は、よくある問題に対する、実証済みの設計上の解決策をまとめ上げた（これは、私が用いた「台所」の例よりはるかに巧妙なものだった。Alexander の本の読者は、台所の例にうんざりしただろう）。そこで意図されていたのは、建築家とユーザがこの言語でコミュニケーションをとることであり、パターンの導きに従い利用者にとって機能的で快適な素晴しい建物を作り出すことである。

15
パターン・ランケージは当書籍である、「パタン・ランゲージ：環境設計の手引」と、
同じくクリストファーアレグザンダー書「時を超えた建設の道」が源流で、GoFの「デザイン
パターン」をはじめ、様々ソフトウェア・パターンに強い影響を与えたと言われています。
自分メモ
アレグザンダーのパターン記述は、結城浩さんがHP上でまとめられています。
「Alexanderのパターン記述」
http://www.hyuki.com/dp/alex.html
時を超えた建設の道

amazon
オブジェクトプログラミングのデザインパターン（こうすればよいパターン）を集めた解説のJ2EE編です。
本書では、Javaの中でも、ライブラリ（部品）の利用方法が難しいJ2EEに絞って、設計上考慮すべき事項とリファクタリング手法の解説の後で、21個の推奨パターンをサンプルコード付きで詳細に解説しています。
J2EE パターン第2 版
16
絶版

●第16章大規模な構造
技術的なアーキテクチャ（J2EE など）によっては、ここ数年で有名になったものもあるが、
ドメイン層における大規模な構造はまだあまり探究されていない。
アプリケーションによって、要求が大幅に異なるからだ。
J2EE パターン第2 版
17

amazon
Smalltalkを実装するうえで、失敗のないようにするためのベストプラクティスが書かれた本である。良いプログラミングスタイルとはどのようなものか、良いソフトウェアとはどのようなものかを実装のレベルで解説している。
ケント・ベックのSmalltalk
ベストプラクティス・パターン―
シンプル・デザインへの宝石集
18
絶版

●第10章しなやかな設計「意図の明白なインターフェース」
Kent Beck は、メソッド名によって目的を伝えることについて、意図の明白な
セレクタ（INTENTION-REVEALING SELECTOR）を用いて説明している（Beck 1997）。
ケント・ベックのSmalltalk ベストプラクティス・パターン
19

オブジェクトの広場での説明文では、XPやリファクタリングを発表する前
に書かれた本で、そこに至る源流が書かれているとの事です。
http://www.ogis-ri.co.jp/otc/hiroba/OoBook/SbppBook/
ケント・ベック本としては、「実装パターン」も実用的で有名ですね。
同じく絶版ですが（涙
ケント・ベックのSmalltalk ベストプラクティス
20
自分メモ
実装パターン
絶版

amazon
XPは単なる机上の空論ではなく、すでにいくつものソフトウェア開発で実績を上げている。
現在実践されているソフトウェア開発方法に不満を持っている人にとって、斬新な視点と方法を与えるだろう。
まず最初に、解決すべき問題点を取り上げ、それを解決するために、どのような方針や戦略を用いればいいかが示される。XPは変化を受け入れ、勇気を持って改良していくことを勧めるのである。
XP エクストリーム・プログラミング入門 ―変化を受け入れる
21
絶版

●まえがき「設計対開発プロセス」
本書は特定の方法論と結びついてはいないが、「アジャイル開発プロセス」という新しいグループを指向している。
～省略～
イテレーション開発は、ここ2、30 年の間、支持され、実践され続けていて、アジャイル開発手法の礎にもなっている。アジャイル開発とエクストリームプログラミング（XP）の文献には優れた議論が多く、『Surviving Object-Oriented Projects』（Cockburn 1998）や、『Extreme Programming Explained』（Beck 1999）などが挙げられる。
---------------------------------------------------------------------------------
●第16章大規模な構造「システムのメタファ」
システムのメタファが著名なアプローチとなったのは、エクストリームプログラミングにおけるコアプラクティスの1つだからだ（Beck 2000）。
残念ながら、本当に役立つメタファが見つかったプロジェクトはほとんどなく、この考え方をドメインに押し込もうとした結果、逆効果になったものもある。
説得力のあるメタファが持ち込むリスクもある。設計に与えられる類比の側面は当面の問題にとって望ましいものでないかもしれず、また、用いられる類比が魅力的であっても適切ではないかもしれないのだ。
XP エクストリーム・プログラミング入門―変化を受け入れる
22

DDD本のまえがきで、DDDは「アジャイル開発プロセス」という新しいグループを指向していると述べています。
確かに、DDDにはアジャイルに関係した「アジュールモジュール」や「アジャイルな設計」など出てきます。
「顧客／供給者の開発チーム」パターンなんてチーム作りですよね。
では、ウォータフォールでDDDはどうなるのかというと、本の中では直接述べられてはいません。
しかし、DDDではモデル実装によるフィードバックを得る事で、より深いモデルへ進めるとあります。（第３章「実践的モデラ」）
ウォーターフォールでは、設計から実装でのフィードバックを得る期間が長くなってしまう事や、設計と実装は別担当者（別会社）などで、知の累積も出来ない事を考えると、ウォーターフォールでのDDDは出来なくはないが、非常に厳しいのではと考えられます。
XP エクストリーム・プログラミング入門―変化を受け入れる
23
自分メモ

amazon
XPの中で「ペアプログラミング」と並んで重要な「テストファースト」「リファクタリング」の2要素に焦点を当てて、テスト駆動開発について具体的に解説。
XPを導入している開発者にとって注目のテキスト。
テスト駆動開発入門
24
絶版

DDD本「第３部より深い洞察へ向かうリファクタリング」では、
常にリファクタリングしておくことで、見えていなかった設計がよりしなやかに、深く進めるとあります。
リファクタリングとテスト駆動開発は、セットのようなものと考えておりますので、DDDを実践するのならば、テスト駆動開発は身に着けておきたい技法と言えると思います。
絶版なのが本当に惜しい。
テスト駆動開発入門
25
自分メモ

amazon
パターンでソフトウェアアーキテクチャを創出するというのは、ソフトウェア開発の新しいアプローチだといえるだろう。
本書は、パターンアプローチを発展させて、大規模アプリケーションを設計、文書化することのできるパターン体系を著したものである。
ソフトウェアアーキテクチャ：ソフトウェア開発のためのパターン体系
26
絶版

●第4章ドメインを隔離する「レイヤ化アーキテクチャ」
ソフトウェアシステムを分割する方法にはあらゆる種類のものがあるが、経験と慣習を通じて業界が収束してきている共通見解はレイヤ化アーキテクチャであり、それも具体的には数個のかなり標準的なレイヤである。レイヤ化というメタファはあまりにも広範に使用されているから、ほとんどの開発者には直観的に感じられる。レイヤ化についての優れた議論の多くは文献として入手可能で、パターンのかたちになっているものもある。
--------------------------------------------------------------------------------
●第16章大規模な構造「システムのメタファ」
特定の概念と活動が生まれる背後で、他の要素がさまざまなスピードとさまざまな理由で、独立して変化する。
この自然な構造を活かし、構造を可視化して役立つものにするには、どうすればよいだろうか？
この階層の形成が示唆しているのはレイヤ化である。
レイヤ化は、最も成功を収めたアーキテクチャ設計パターンの1つである（Buschmann 他1996 など）。
27

●第16章大規模な構造「責務のレイヤ」
責務のレイヤに最適なレイヤ化パターンは緩やかなレイヤ化システム（RELAXED LAYERED SYSTEM）（Buschmann 他1996, p.45）と呼ばれるものの変種である。
これはあるレイヤのコンポーネントが直下のレイヤだけでなく、どの下位層へもアクセスできるようにするものだ。
--------------------------------------------------------------------------------
●第16章大規模な構造「知識レベル」
知識レベルはリフレクション（REFLECTION）パターンをドメイン層に適用したものだ。
リフレクションは多くのソフトウェアアーキテクチャや技術的なインフラストラクチャに使用されており、『ソフトウェアアーキテクチャ―ソフトウェア開発のためのパターン体系』（Buschmann 他1996）で詳述されている。
28

建築家がこの考え方についてどう思っていたかはともかく、パターンランゲージはソフトウェア設計に大きな影響を与えた。
1990 年代、ソフトウェアパターンはいろいろな方法で適用され、いくらかの成功を収めたのだが、そのなかで注目すべきなのは、詳細な設計（Gamma他1995）と技術的アーキテクチャ（Buschmann 他1996）である。
29

この本も有名なパターン本ですよね。
レイヤ・パターンは、この本が元だとは知りませんでした。
（考え方の源流は、オブジェクト指向そのものに行き着くと思われますので、名づけ元でしょうか？）
オブジェクトがもつ責務を、本当に上手くレイヤという概念で表現されたと思います。エバァンスも「最も成功を収めたアーキテクチャ設計パターンの1 つ」とまで誉めています。
レイヤはMVCパターンをはじめ、基本概念になっていると思います。
DDD本では「ドメイン層」などの「レイヤ化アーキテクチャ」パターンに加え、「責務のレイヤ」パターンにもレイヤが使われています。
30
自分メモ

amazon
プログラミングでいうところのオブジェクト指向の持つメリット、すなわち変化への影響を最小化させ、健全なビジネスモデルを作成することは、そのまま組織にも適用できる。
しかし、オブジェクト指向プロジェクトは、いまだ組織にとって新しい行動様式である。
本書は、著者が数十のオブジェクト指向プロジェクトを通じて得た教訓や対処法を、具体的に解説した1 冊である。
アジャイルプロジェクト管理
31
絶版

DDD本の参考文献で初めて、当書のことを知りました。
紹介文にある「著者が数十のオブジェクト指向プロジェクトを通じて得た教訓や対処法を、具体的に解説した1冊」という処が気になりましたので、中古本（絶版なので）探して読んでみたいと思います。
アジャイルプロジェクト管理
32
自分メモ

Eric Evans とMartin Fowler が1997年に行われたPLoP(Pattern Languages of Programs) ConferencesのProceedings(討論会？)にて、 Specifications(仕様もしくは、形式)について話した資料。
“Specifications.”
Proceedings of PLoP 97 Conference.
33

（追記）
当初資料は無いと思っていたのですが、@spring_kumaさんに
資料PDFがある事を教えて頂きました。有難うございます！
http://martinfowler.com/apsupp/spec.pdf
“Specifications.”
Proceedings of PLoP 97 Conference.
34

●第9章暗黙的な概念を明示的にする
「ドメインオブジェクトとしてのプロセス」
仕様を用いることで、ある種のルールを表現し、それらのルールを条件つきロジックから解放し、モデルの中で明示することが、簡潔にできるようになる。
私はこの仕様をMartin Fowler と共同で開発した（Evans and Fowler 1997）。
“Specifications.” Proceedings of PLoP 97 Conference.
35

荒読みですが、DDD本の「仕様」パターンをより詳しく書かれている資料のようです。
とても詳しく書かれておりますので、時間がかかっても資料読んでみたいと思います。（英語苦手）
“Specifications.” Proceedings of PLoP 97 Conference.
36
自分メモ

amazon
紹介文（翻訳＆抜粋）
ドメイン固有のアプリケーションフレームワークは、新しいアプリケーションを生成するために、無期限に、再利用できる汎用的なソフトウェアアーキテクチャを提供する、ドメイン固有フレームワークの貴重なコレクションオブジェクトです。
各章は、主要フレームワーク実装やカスタマイズプロジェクトを報告するケーススタディを中心に、構築されています。
Domain-Specific Application Frameworks
37

●第16章大規模な構造「着脱可能コンポーネントのフレームワーク」
Fayad とJohnson（2000）は、SEMATECH CIMに関する議論を含むいくつかのドメインにおいて、着脱可能コンポーネントのフレームワークに向けた意欲的な取り組みを詳細に観察している。
～略～
着脱可能コンポーネントのフレームワークは、プロジェクトで大規模な構造を適用するにあたり、最初に取り組んではならない。
最も成功した例では、複数の専用アプリケーションが完全に開発された後に、このパターンが適用されていた。
38

残念ながら、翻訳本は無いようです。
日本語圏でも当書に関する情報は少なく、英語圏で情報を集めるしかな
さそうです。
amazonの紹介文「ドメイン固有のアプリケーションフレームワークは、新
しいアプリケーションを生成するために、無期限に、再利用できる汎用的
なソフトウェアアーキテクチャを提供する」を見る限り、面白そうな本なの
ですが、なかなか手を出す決心がつかないですね（笑
当書が紹介されている「着脱可能コンポーネントのフレームワーク」パ
ターンは、エヴァンス曰く「適用するのが非常に難しいパターンだというこ
とである。インタフェースは正確に設計する必要があり、抽象化されたコ
アで必要なふるまいをとらえられるだけの深いモデルがなければならな
い。」など、なんだか難易度が高そうです。
39
自分メモ

amazon
オブジェクトモデルを開発し、共有すべきオブジェクトを提供する人に対して、オブジェクトモデル開発の方法を、オブジェクト関連のパターンで誘導する。
アナリシスパターン―
再利用可能なオブジェクトモデル
40
絶版

●第4章ドメインを隔離する「レイヤ化アーキテクチャ」
ドメイン層をインフラストラクチャ層とユーザインタフェース層から分離することにより、各レイヤをはるかに明確に設計できるようになる。
～略～
このように分離することで、分散システムにも配置しやすくなる。
別々のレイヤを、それぞれ別々のサーバやクライアントに柔軟に配置できるようにすることで、通信のオーバーヘッドを最小化して、性能を向上させることができるのだ（Fowler 1996）。
-------------------------------------------------------------------------------
●第7章言語を使用する応用例
「モデルを強化する：ビジネスのセグメント化」
時には、分析パターンからモデリングに関する解決策が得られることもある。『アナリシスパターン』（Fowler 1996）には、この種の問題に取り組むパターンが記述されている。それが、エンタープライズセグメント（ENTERPRISE SEGMENT）だ。
エンタープライズセグメントとは、ビジネスの分割方法を定義した次元軸の集まりである。
～略～
この概念を配分のモデルで使用することで、モデルはより表現力豊かになり、インタフェースはシンプルになる。
アナリシスパターン―再利用可能なオブジェクトモデル
41

●第9章暗黙的な概念を明示的にする「何度でも挑戦すること」
該当するドメインの開発経験があるソフトウェアの専門家が書いた文献を読むという方法がある。例えば、『アナリシスパターン』（Fowler 1997）の第6章を読んでいたら、いいか悪いかは別として、全く異なる方向へ進んだはずだ。
そうした読書では既製の解決策は得られなかっただろう。
ただ、開発者自身の実験に新しい出発点をいくつか準備できたかもしれず、そこに、過去に同じ分野を探究した人々の蒸留された経験も加わったはずだ。車輪の再発明を避けられたに違いない。
-------------------------------------------------------------------------------
●第11章アナリシスパターンを適応する
『アナリシスパターン』においてMartin Fowler は、自身のパターンを次のように定義している。
アナリシスパターンとは、ビジネスモデリングにおける共通の構造を表す、概念のグループである。ただ1 つのドメインにしか適さないものもあれば、多くのドメインに及ぶものもある。（Fowler 1997, p.8）
42

●第15章蒸留「蒸留の拡大」
要求に完全には合致していないかもしれないし、要求に対して作り込みすぎているかもしれない。
～略～
これが最もうまくいくのは、『アナリシスパターン』（Fowler 1996）で書かれているような、広く流通しているモデルがある場合だ。
-------------------------------------------------------------------------------
●第16章大規模な構造「知識レベル」
『アナリシスパターン』（Fowler 1996, p.24-27）において、このパターンは組織内の説明責任（accountability）をモデル化する議論から現れ、その後、会計の記帳ルールに適用されている。
このパターンは同書で複数の章に出てくるものの、独立した章にはなっていない。これは、その他のほとんどのパターンとは異なっているためだ。他のアナリシスパターンのようにドメインをモデル化するのではなく、知識レベルは、モデルを構造化するのである。
43

最初、当書を読んだときは、あまりの難しさに途中で読むのを諦めました。今回改めて読んでみたのですが、やっぱり難しいです。
恐らく、知識の量が圧倒的に足りていないのだと思いますＯＴＺ
エンタープライズセグメント（ENTERPRISE SEGMENT）などは、理解できたら本当に強力な武器になりそうです。
もう少しモデリング知識を身に着けてから再チャレンジしたいと思います。
44
自分メモ

amazon
http://www.amazon.co.jp/dp/427405019X
プログラムに潜む扱いにくい部分を見つけ出し、その動作を変えずに内部の構造を改善していくためのテクニックを整理したマーティン・ファウラー氏によるソフトウェア開発の名著『リファクタリングプログラミングの体質改善テクニック』が、オリジナルの訳者による丁寧な見直しと現代的なJava開発環境による「再リファクタリング」を施した書き下ろし付録を収録して再発行!
リファクタリング―プログラムの
体質改善テクニック
45
祝!復刻

●第3 部より深い洞察へ向かうリファクタリング「リファクタリングのレベル」
『リファクタリング』（Fowler 1999）に挙げられているカタログは、定期的に話題に上るマイクロリファクタリングのほとんどを網羅している。
それらのリファクタリングを行う動機となっているのは、コード自体の中に見つけることのできる問題である。
それとは対照的に、新たな洞察が現れた時には、ドメインモデルはきわめて広い範囲にわたって変化するので、包括的なカタログにまとめることができない。
-------------------------------------------------------------------------------
●第10章しなやかな設計「副作用のない関数」
値オブジェクトは不変である。
このことは、生成時にのみ呼び出されるイニシャライザを別にすると、すべての操作が関数であることを示唆している。
関数と同じように、値オブジェクトも安全に使用することができ、テストも容易である。
ロジックや演算が状態の変更と混在している操作は、リファクタリングして2 つの別々の操作にすべきである（Fowler 1999, p.279）。
リファクタリング―プログラムの体質改善テクニック
46

読者の強い要望があったのか、無事復刻（新装版）が出版されて本当に良かったです。
今読み返してみると、何故リファクタリングするのか、モデルを考えよというのは書いていたのですね。
単なるテクニック集だと、思い込んでいました。ホント勿体無い読み方をしておりました。
ＤＤＤ本では、リファクタリングの重要性を強く説いています。
リファクタリングとテスト駆動開発をセットで、もう一度読み直したいと思います。
リファクタリング―プログラムの体質改善テクニック
47
自分メモ

amazon
エンタープライズアーキテクチャのレイヤ化とは？
エンタープライズアプリケーション開発は、多くの新しい技術の出現から利益を得てきました。
本書は、エンタープライズアプリケーション開発者が直面するやっかいな課題に対する直接的な回答を示したものです。
本書は40以上のパターンを紹介しています。これらは、エンタープライズアプリケーションプラットフォームに適用可能な解決策です。
エンタープライズアプリケーション
アーキテクチャパターン
48

●第４章ドメインを隔離する「レイヤを関係づける」
ユーザインタフェースをアプリケーション層とドメイン層に結びつけるパターンの父祖に当たるのは、モデル・ビュー・コントローラ（MVC： MODEL-VIEW-CONTROLLER）である。
これは遡ること1970 年代にSmalltalk の世界で開拓され、後続の多くのUI アーキテクチャにインスピレーションを与えてきた。
Fowler（2002）は、このパターンと、こうしたテーマに関する便利なバリエーションを論じている。
-------------------------------------------------------------------------------
●第４章ドメインを隔離する「利口なUI アンチパターン」
利口なUI とレイヤ化アーキテクチャとの中間には、他にも解決策がある。例えば、Fowler（2002）が説明しているトランザクションスクリプト（TRANSACTION SCRIPT）は、ユーザインタフェースをアプリケーションから分離はするが、オブジェクトモデルは提供しない。
要はこういうことである。アーキテクチャがドメインに関連するコードを隔離して、凝集度が高いドメインの設計が、システムの他の部分と疎結合できるようにしているなら、そのアーキテクチャはおそらくドメイン駆動設計を支えられるだろう。
エンタープライズアプリケーションアーキテクチャパターン
49

●第6章ドメインオブジェクトのライフサイクル「リポジトリ」
ドメイン駆動設計の目標は、技術ではなくドメインについてのモデルに焦点を合わせることによって、よりよいソフトウェアを作ることである。
～略～
メタデータマッピング層（METADATA MAPPING LAYERS）（Fowler 2002）のようなインフラストラクチャは、非常に役立つもので、クエリの結果をオブジェクトへ容易に変換できるようにしてくれるが、それでもまだ開発者が考えているのは、ドメインではなく技術的な仕組みなのである。
-------------------------------------------------------------------------------
データベースアクセスに起因する技術的な課題に対処するテクニックは多数ある。
例えば、SQL をクエリオブジェクト（QUERY OBJECT）にカプセル化することや、メタデータマッピング層（Fowler 2002）でオブジェクトとテーブル間の変換を行うことなどが挙げられる。
ファクトリは格納されたオブジェクトを再構成するのに役立つ。
この他にも多くのテクニックにより、複雑さを隠しておける。
50

仕様に基づいたクエリはエレガントで柔軟性がある。
利用可能なインフラストラクチャ次第で、そう複雑でないフレームワークになることもあれば、恐ろしく難解になることもある。
『エンタープライズアプリケーションアーキテクチャパターン』（Fowler 2002）において、Rob Mee と Edward Hieatt が、そういうリポジトリの設計にまつわる技術的問題について議論している。
-------------------------------------------------------------------------------
リポジトリと、クエリオブジェクトのようなそれをサポートする技術的なパターンの実装に関しては、さらなる指針が『エンタープライズアプリケーションアーキテクチャパターン』（Fowler 2002）に書かれている。
51

●第6章ドメインオブジェクトのライフサイクル
「関係データベースに合わせてオブジェクトを設計する」
データベースは、オブジェクトと相互作用するだけではなく、オブジェクト自体を構成しているデータを永続化のための形式で格納することもできるのだ。
オブジェクトを関係テーブルへマッピングさせ、効果的に格納し取り出すことに関する技術的な課題については、これまでも数多論じられてきた。
最近の議論は『エンタープライズアプリケーションアーキテクチャパターン』（Fowler 2002）に見られる。
-------------------------------------------------------------------------------
●第9章暗黙的な概念を明示的にする「仕様の適用と実装」
ここでの議論は、仕様をデータベースと組み合わせるという課題の表層をなぞっているにすぎないので、起こり得る考慮事項をすべて網羅しようとはしていない。
私は、どういった選択をしなければならないかを少し紹介したかっただけなのだ。Mee とHieatt が、リポジトリを仕様と合わせて設計することに伴う技術的な問題のいくつかを『エンタープライズアプリケーションアーキテクチャパターン』（Fowler 2002）で議論している。
52

最近では、基本的なオブジェクト指向設計テクニック（Larman 1998）とエンタープライズアーキテクチャ（Fowler 2002、Alur 他2001）をドキュメント化するのにパターンが使用されている。
パターンの言語は、今やソフトウェア設計に関する考えをまとめる上で、主流のテクニックとなっている。
53

当書を使いこなせているかというと、微妙（汗
「Active Record」パターンや、「Transaction Script」パターンなどは使っていますが、「Domain Model」パターンなどは使った事がありません。
（読み返して存在を知ったぐらい・・・あれ？）
リファクタリング本同様に、テクニックパターン集という認識で読んでいた為、使えそうなパターンを使えそうな箇所に使って、満足している状態でした。何てもったいない本の読み方をしていたのでしょう。(TωT)ｳﾙｳﾙ
DDD本的には、「リポジトリ」パターンに代表されるように、DBとの依存性を制御するパターン集として紹介されています。
技術ではなくモデルに焦点を合わせるという視点で、学び直したいと思います。
54
自分メモ

amazon
本書は柔軟で、再利用可能な、理解しやすい設計のために、オブジェクト指向ソフトウェア設計において遭遇するさまざまな問題に対する解法を、23個のデザインパターンとしてカタログ化。
あなたのプログラムにも、即、適用できます。
オブジェクト指向における再利用の
ためのデザインパターン改訂版
55

●第１章知識をかみ砕く「隠された概念を引き出す」
オーバーブッキングのルールは、ポリシーである。
ポリシーとは、ストラテジーとして知られている設計パターンの別名だ。
-------------------------------------------------------------------------------
レイヤ同士は疎結合であるべきで、設計の依存関係は1方向にだけ向けられる。上位のレイヤは、下位のレイヤにある要素を直接使用したり操作したりできる。
～略～
そのために活用されるのが、コールバックやオブザーバ（OBSERVER）（Gamma 他1995）といった、レイヤ同士を関係づけるためのアーキテクチャパターンである。
オブジェクト指向における再利用のためのデザインパターン改訂版
56

●第5章ソフトウェアで表現されたモデル「値オブジェクトを設計する」
値オブジェクトは数が多くなりがちだからだ。
家の設計を行うソフトウェアの例がこのことを示唆している。電気のコンセントそれぞれが別個の値オブジェクトだったら、家1件の見取り図の1バージョンに対して、そのオブジェクトが100個できるかもしれない。
しかし、すべてのコンセントが相互に交換できると見なせば、コンセントのインスタンス1つだけを共有し、それを100回参照すればよい（フライウェイト（FLYWEIGHT）（Gamma他1995）の一例）。
-------------------------------------------------------------------------------
●第5章ソフトウェアで表現されたモデル「サービスへのアクセス」
サービスへのアクセスを提供する手段は、特定の責務を切り出すという設計上の意思決定ほどには重要ではない。
サービスのインタフェースを実装するのに、「実行者」オブジェクトで十分な場合もある。
単純なシングルトン（SINGLETON）（Gamma 他1995）は、アクセスを提供するために簡単に作成できる。
57

●第6章ドメインオブジェクトのライフサイクル「ファクトリ」
ファクトリの設計方法は数多くある。
ファクトリメソッド（FACTORY METHOD）、抽象ファクトリ（ABSTRACT FACTORY）、ビルダ（BUILDER）といった特別な目的を持つ生成パターンは、『デザインパターン』（Gamma 他1995）において詳述されている。
～略～
だが、ここで重要なのは、ファクトリの設計を掘り下げることではなく、ドメイン設計における重要なコンポーネントとして、ファクトリの居場所を示すことである。ファクトリを適切に使用すれば、モデル駆動設計を順調に進められる。
-------------------------------------------------------------------------------
●第6章ドメインオブジェクトのライフサイクル「ファクトリ」
ファクトリは、生成される具象クラスではなく、要求される型に応じて抽象化しなければならない。
これには、『デザインパターン』（Gamma 他1995）で紹介されている、洗練されたファクトリパターンが役に立つ。
58

●第7章言語を使用する応用例「シナリオをウォークスルーする」
リピータへの対応ユーザとしては、同じ顧客によって繰り返される予約は似ている傾向があるので、新規の貨物のプロトタイプとして古い貨物を使用したい。
そのため、アプリケーションでは、ユーザがリポジトリから貨物を検索した後で、選んだ貨物を基に新規の貨物を生成するコマンドを選択できるようにする。これは、プロトタイプパターン（PROTOTYPE）（Gamma 他1995）を使用して設計することにしよう。
-------------------------------------------------------------------------------
●第3 部より深い洞察へ向かうリファクタリング「発見のプロセス」
リファクタリングの目標としてのパターンという考え方は、『デザインパターン』（Gamma 他1995）で簡単に言及されている。
59

●第12章デザインパターンをモデルに結び付ける
第一に、よく知られている書籍、『デザインパターン』の著者たちは次のように述べている。
～略～
この本では、我々はあるレベルまで抽象化されたパターンに専念した。
～略～
本書でいうデザインパターンは、オブジェクトやクラスとコミュニケーションすることに関する記述であり、一般的な設計の問題を特定のコンテキストで解決するためにカスタマイズされているのだ。（Gamma他1995, p.3）
-------------------------------------------------------------------------------
アルゴリズムのファミリーを定義し、それぞれをカプセル化して、相互に交換可能にする。ストラテジーによって、アルゴリズムは、それを使用するクライアントから独立して変化できるようになる。（Gamma他1995）
60

オブジェクトを組み立てて、部分と全体の階層を表すツリー構造を作ること。コンポジットを使うことで、クライアントは、個々のオブジェクトとオブジェクトの複合体を一様に扱えるようになる。（Gamma他）
-------------------------------------------------------------------------------
●第14章モデルの整合性を維持する「腐敗防止層」
腐敗防止層の設計を構成する方法の1つに、ファサード（FACADE）とアダプタ（ADAPTER）（どちらもGamma他1995 より）および変換サービスを組み合わせ、システム間の通信に通常必要となるコミュニケーションと転送の仕組みと合わせて使う、というものがある。
61

●第14章モデルの整合性を維持する「腐敗防止層」
ここでのアダプタという用語の使い方はあまり厳密ではない。
『デザインパターン』（Gamma他1995）で強調されていたのが、ラップされたオブジェクトをクライアントが期待する標準インタフェースに従わせるということだったのに対して、ここでは適合（アダプト）したインタフェースを選ぶことができる上、適合される側はおそらくオブジェクトでさえないからである。
我々が強調しているのは、2つのモデル間で行われる変換だが、私はこれもアダプタの意図と一致していると考えている。
-------------------------------------------------------------------------------
建築家がこの考え方についてどう思っていたかはともかく、パターンランゲージはソフトウェア設計に大きな影響を与えた。1990 年代、ソフトウェアパターンはいろいろな方法で適用され、いくらかの成功を収めたのだが、そのなかで注目すべきなのは、詳細な設計（Gamma他1995）と技術的アーキテクチャ（Buschmann 他1996）である。
62

デザインパターン本も、テクニック本として見ておりました。
使い方も使えそうな箇所に、デザインパターンを配置してみるという形で
モデル・ドメインなんて全く考えておりませんでした。
DDD本を読んだ後、何となくデザインパターン本を読んでみると、今まで
とは違う形に見え、デザインパターンへの認識がガラリと変わったのが大
変な驚く気でした。（この資料を作ったきっかけでもあります）
「Flyweight」「Adapter」「Facade」や、「Abstract Factory」「Prototype」など
やっと理解できた気がします。
もう一度、「オブジェクト指向のこころ」も読み直したいと思います。
63
自分メモ
オブジェクト指向のこころ
祝!復刻

DDD本が出版された後の2004年に、「Refactoring to Patterns」という本で出版されました。
また、その後2005年に和訳本「パターン指向リファクタリング入門～ソフトウエア設計を改善する27の作法」が出版（今は絶版）。
“Continuous Learning,”
in Extreme Programming Perspectives.
http://www.industriallogic.com/xp/refactoring
64
絶版

amazon
「デザインパターン（パターン）」を目指して「リファクタリング」する手法を解説し、パターンとリファクタリングの両方が学べる実践的な教科書です。
リファクタリングの道しるべとして「パターン」をとらえることで、リファクタリングの幅が広がる一方で、デザインパターンがどういったものかは理解しつつも、なかなか実際のソフトウエアの設計でうまく生かせない方には、パターンの有効な使い方が学べます。
パターン指向リファクタリング入門~
ソフトウエア設計を改善する27の作法
65
絶版

●第１章知識をかみ砕く「継続的学習」
ソフトウェアを書き始める時、我々は対象を十分に理解しているわけではない。
～略～
高度に生産的なチームは、自分たちの知識を意識的に育てて、継続的学習を実践する。開発者にとって、これが意味するのは、（本書にあるような）一般的なドメインモデリングのスキルと合わせて、技術的な知識を向上させるということだ。
-------------------------------------------------------------------------------
●第3 部より深い洞察へ向かうリファクタリング
「発見のプロセス」
リファクタリングの目標としてのパターンという考え方は、『デザインパターン』（Gamma 他1995）で簡単に言及されている。
Joshua Kerievsky は、パターンへのリファクタリングをより成熟した有用な形式に発展させた（Kerievsky 2003）。
パターン指向リファクタリング入門
66

DDD本の参考文献では、URL（http://www.industriallogic.com/xp/refactoring）だけが、記載されているのですが、その後該当ページは出版され「Refactoring to Patterns」、和訳「パターン指向リファクタリング」が出版されたものと考えております。
当書についてですが、めちゃくちゃ良い事書いてます。（またかｗ
パターンを使用する時の難しい所は、
・パターンの使いどころ
・実装済みからのパターンへの変更
などがあるので、私は何となくパターンを使うという形で逃げていたのですが、当書ではそれらを丁寧に解説されておりました。
なかなか無い名著だと思います。
残念ながら、絶版となっておりますので、気になる方はお早めに手に入れられた方がよさそうです。
パターン指向リファクタリング入門
67
自分メモ

amazon
本書は、OOA/D（オブジェクト指向分析／設計）および反復型開発の関連事項について実践的な解説をおこない、UMLやパターンを実際の開発で活用していく方法を学びます。
良質な設計、UP(統一プロセス)のアジャイルなアプローチ、適切なモデリング、実践的なデザインパターンなどを含め、OOA/Dを包括的に身につけることができます。
実践UML 第3 版
オブジェクト指向分析設計
と反復型開発入門
68
絶版

●第2 部モデル駆動設計の構成要素
本書の設計スタイルは、「責務駆動設計（responsibility-driven design）」の原則に従うところが大きい。
～略～
また、オブジェクト指向設計のベストプラクティスとして広く受け入れられ、『実践UML』といった書籍において説明されている、その他の一般的な背景とも、本書は矛盾しない。
-------------------------------------------------------------------------------
ユーザインタフェースをアプリケーション層とドメイン層に結びつけるパターンの父祖に当たるのは、モデル・ビュー・コントローラ（MVC）である。
～略～
また、Larman（1998）は、こうした関心についてモデル／ビュー分離パターン（MODEL-VIEW SEPARATION PATTERN）において調査していて、その中にあるアプリケーションコーディネータ（APPLICATION COORDINATOR）は、アプリケーション層を結びつけるアプローチの1つである。
実践UML 第3 版オブジェクト指向分析設計と反復型開発入門
69

●第5章ソフトウェアで表現されたモデル「モジュール」
低結合と高凝集は、一般的な設計の原則であり、モジュールに対するのと同じように、個々のオブジェクトに対しても適用される。
しかし、より粒度の大きいこのようなモデリングと設計においては、とりわけ重要なのだ。
これらの用語は長いこと使用されてきており、パターン形式での説明は『実践UML』（Larman 1998）に見られる。
-------------------------------------------------------------------------------
最近では、基本的なオブジェクト指向設計テクニック（Larman 1998）とエンタープライズアーキテクチャ（Fowler 2002、Alur 他2001）をドキュメント化するのにパターンが使用されている。
パターンの言語は、今やソフトウェア設計に関する考えをまとめる上で、主流のテクニックとなっている。
70

実践UMLとタイトルにありますが、UMLに留まらず、オブジェクト指向全般や、分析、実装について書かれています。 GRASPの法則の本としても有名ですね。
•General（汎用）
•Responsibility（責任）
•Assignment（割り当て）
•Software（ソフトウェア）
•Patterns（パターン）「GRASPの法則」と、そこから派生する「低結合」と「高凝集」の考え方は、 DDDの骨格を成していると考えています。
71
自分メモ

amazon
http://amzn.com/B000M4IQSW
Hard cover dictionary vg as seen, no dust cover. We ship worldwide from San Francisco bay area.
※アメリカの辞書。
Merriam-Webster's Collegiate Dictionary, Tenth Edition
72

amazon
オブジェクト指向入門第2版原則・コンセプト
オブジェクト指向入門第2版方法論・実践
原理原則から分析設計へ!!
オブジェクト指向のすべてがこの中にある!!
現在でもソフトウェア開発に携わる人々には欠かす事のできない必読書として多くの支持を得ています。
オブジェクト指向入門第2 版
原則・コンセプト、方法論・実践
73

本書の設計スタイルは、「責務駆動設計（responsibility-driven design）」の原則に従うところが大きい。
～略～
また、『オブジェクト指向入門』（Meyer 1988）で説明されている「契約による設計（design by contract）」の考え方からも、（特に第3 部で）多くを引き継いでいる。
-------------------------------------------------------------------------------
●第10章しなやかな設計「副作用のない関数」
ほとんどのソフトウェアシステムがコマンドを使わずにいられないのは明らかだが、この問題を抑える方法は2つある。
第一に、コマンドとクエリを別々の操作に厳密に分離しておくことができる。変更を引き起こすメソッドに関して、ドメインデータを戻さないようにすることと、可能な限りシンプルに保つことを保証すること。
クエリと演算はすべて、目に見える副作用を起こさないメソッドで実行すること（Meyer 1988）。
オブジェクト指向入門第2版原則・コンセプト、方法論・実践
74

●第10章しなやかな設計「表明」
このスタイルは『オブジェクト指向入門』（Meyer 1988）において詳述されている。
要約すると、「事後条件」（post-conditions）が操作の副作用、つまり、メソッドを呼び出すことで保証される結果を記述する。
「事前条件」（preconditions）とは契約にあるただし書きのようなもので、事後条件が成り立つことを保証するために満たさなければならない条件のことである。
75

鈍器。
入門させてくれない入門書。
名著として有名な当書ですが、、「事前条件」、「事後条件」の概念が
一番印象に残っています。
この本を読むまでは、例外とは何か？という答えを持っていなかったのですが、本を読むことで整理できました。
（事前条件で、対応できなかったエラーが例外となります。）
DDD本としては、「事前条件」「事後条件」に加え、「不変表明」の概念などが使われています。
76
自分メモ

CML （Chemical Markup Language）。
HTMLのアイデアを応用し、化学式や化学反応などの化学情報を
WEB上で交換や、共同研究しやすくするための化学マークアップ言語として、1995年シカゴACS会議にて発表された40の要旨。
Abstract 40.
Presented as a poster at the 210th ACS Meeting in Chicago http://www.ch.ic.ac.uk/cml/
77

●第14章モデルの整合性を維持する「公表された言語」
そこに現れたのが化学マークアップ言語（CML: Chemical Markup Language）というXML の方言である。CMLはこのドメインの共通交換言語となるよう意図されたもので、学会と業界を代表するグループによって開発され、管理されている（Murray-Rust 他1995）。
Abstract 40. Presented as a poster at the 210th ACS Meeting in Chicago
78

DDD本では、「公表されたメタ言語」であるXMLを応用した、CMLを利用することで、ドメイン情報を必要に応じて変換する実例として、当資料が紹介されました。
DDD的に「公表」とは、その言語を使用することに関心があるコミュニティが、いつでもその言語を入手できる状態にあり、それぞれの解釈が互換性を持つように、十分にドキュメント化されているという意味になります。
Abstract 40. Presented as a poster at the 210th ACS Meeting in Chicago
79
自分メモ

amazon
言語を生みだす本能〈上〉
言語を生みだす本能〈下〉 http://www.amazon.co.jp/dp/4140017414
子どもは、統語体系の設計図をもって誕生し、クモが巣を作るように、母語を本能で獲得する。
世界的言語学者が、チョムスキー理論を越えて、言語獲得の謎を実証的に解き明かす。
言語を生みだす本能
80

●第2章コミュニケーションと言語の使い方「声に出してモデリングする」
モデルを改良する最適な方法の1 つは、話してみることだ。考えられるモデルのバリエーションから生じるさまざまな概念を、声に出して構成してみる。粗削りな表現は聞けばすぐわかる。
～略～
実際のところ、我々の脳は、話し言葉の複雑さに対応することにやや特化していると思われる（私のような素人向けの優れた参考書は、Steven Pinker の『言語を生みだす本能』だ）。
81

DDDでは、モデルを改良する最適な方法の1つとして、「声に出してモデリングする」というのがあります。
声に出すことで、図を書いて検証するのと同じように、
モデルの不自然さや、荒削りの箇所を見つける事ができるとのことです。
当書は、一般的に言われていた「人の思考能力は、使用している母国語によって枠づけられる」という説を実証的にしりぞけ、「人間が言語を使えるのは、クモが巣を作ったり、コウモリが超音波で外界を知覚したりするのと同様に、人間という種に特有の本能なのである」と言っています。
DDDとしては、ユビキタス言語を使って全員が会話を繰り返す事によって、第二言語を覚えるのと同様に、ユビキタス言語の細かいニュアンスを学び、より深いモデルへ進めると考えているようです。
82
自分メモ

amazon
http://amzn.com/0201770059
XPの役立つ視点を支援し、組織内でXPを実施するための最良の方法を整理します。
Extreme Programming Perspectives
83
絶版

「XP エクストリーム・プログラミング入門―変化を受け入れる」に引き続き2冊目のXP本です。
翻訳されてないこともあり、日本語での情報は殆どなく、英語サイトも探しましたが、本の内容については把握しきれませんでした。
XP関連本が2冊参考文献に記載されていることからも、DDDにとって、
XPの概念は大切なのだろうと推測できます。
Extreme Programming Perspectives
84
自分メモ

amazon
http://amzn.com/0201379406
OCLは、ユーザモデル中だけでなく、UML自体の定義で有用な機能を正式にモデルの制約を表現するための言語を提供することで、UMLを補完します。
この本は、ソフトウェアアーキテクト、設計者、および開発者のためのOCLに実用的なガイドです。
The Object Constraint Language: Precise Modeling with UML
85

●第9章暗黙的な概念を明示的にする「明示的な制約」
制約によってオブジェクトの基本的責務があいまいになっている場合、あるいは、制約がドメインではっきりと見てとれるのにモデルではそうでない場合、制約を括り出して明示的に1オブジェクトにするか、オブジェクトの集まりとそれらの関係性としてモデル化してもよい
（このテーマを詳細かつ正式に近いかたちで扱っている例は『The Object Constraint Language: Precise Modeling with UML』（Warmer and Kleppe 1999）にある）。
86

OCL（Object Constraint Language：オブジェクト制約言語）という存在を
知りませんでした。
当書には新装版「Object Constraint Language, The: Getting Your
Models Ready for MDA」があり、こちらに関しては翻訳が出ておりました。
時間があるときに読んでみたいと思います。
87
自分メモ
UML/MDAのためのオブジェクト制約言語OCL 第2版

amazon
本書は、オブジェクト指向設計の入門/実践書です。
オブジェクト指向プログラミングの経験を問わず、オブジェクト指向設計の基本をしっかりと理解することができます。
著者の経験に基づいた設計のガイドライン、オブジェクトの見つけ方や相互作用に対する考え方、デザインパターン適用時の検討ポイント、わかりやすい設計の記述方法など、実践的かつ幅広く応用できる内容になっています。
オブジェクトデザイン
88

本書の設計スタイルは、「責務駆動設計（responsibility-driven design）」の原則に従うところが大きい。この原則は、1990 年にWirfs-Brock らによって提起され、2003 年に改訂された。
89

エヴァンスが、『DDD本は「責務駆動設計（RDD）」の原則に従う』と書い
ている通り、RDDは根底に存在している気がします。
• オブジェクトを見つける
• 責務を与える
• オブジェクトをコラボレーションさせる
これら概念は、ユビキタス言語に近い物を感じます。
また、「責務のレイヤ」パターンでは、オブジェクト個々の責務ではなく、
ドメイン全体に適応させ、責務毎にレイヤ分けする形に利用しています。
この章を読んだとき、はじめてドメイン層とはこんな感じなのかなと、
理解できた気がしました。
90
自分メモ

参考文献をまとめていて思ったことは、DDD本は、様々な本の寄せ集めではなく、見事に集約・昇華させているソフトウェア工学の集大成の１つだと感じたことでした。
名著だと言われている理由がやっと実感できました。
DDD本を読む事で、色々な知識が繋がっていくのは、実に爽快です。
逆に、DDD本に流れる思想の根底を知らないと理解が難しいなぁと感じる事も多々あります。
（まだまだ、ふんわりとしか理解出来ていないです）
まとめ（１）
92

残念なことは、参考文献の多くは絶版になってしまっている事です。
（特にピアソンショック！）
中古本で手に入る書籍や、概念を継承した新しい書籍があるのなら、良いのですが、全部がそうではありませんので、電子本などで是非、
復刻してほしいと思います。
（実践UMLやパターン指向リファクタリングなどは今読んでも色あせない名著だと思います）
まとめ（２）
93

以上、ご清聴ありがとうございました。
94

Base DDD(ドメイン駆動設計） 参考文献を巡る旅

More Related Content