Kei Sugimoto, “Two Domain Models - An Implication of DDD”, PHP Mentors, (December 20, 2015)

 ドメイン駆動設計（Domain-Driven Design: DDD）は、オブジェクト指向、デザインパターン、リファクタリングなど、ソフトウェア設計分野における幅広い知的遺産と交差します。それゆえ、ドメイン駆動設計は、ドメイン指向のアプリケーションソフトウェア開発に馴染むような仕方でこれらの知識資産を統合したものと見ることができます。

こうした見方は妥当でかつ生産的でもありますが、DDDの業績に対しては別の見方もあり得ます。それがこの短い論考のテーマです。

この文脈において、DDDは、「ソフトウェア設計」から、私たちが特別な思い入れを込めて「情報設計」と呼ぶものへの静かな出発として考えることができるかもしれません。

ドメインモデルとは何か

とはいえ、まずは入口から始めましょう。私たちは1つの基本的な質問について再考しなければいけません：ドメインモデルとは何でしょうか？

ばかばかしい。ドメインモデルはドメインのモデルです。そうではありませんか？

具体的な例を用いて検討しましょう。バージョン管理システム（Version Control System: VCS）です。現在私たちは束にできるほどたくさんのVCSを持っていて、そのいずれもが他といくらか異なるモデルを提供しています。例えば、Subversionでは「コミット」は中央の（かつ単独の）リポジトリへのソースコードの変更の登録を意味するのに対して、Gitでは同じ言葉が分散された一群のリポジトリの特定のメンバーへのソースコードの変更の登録を意味します。「コミット」はそれぞれのVCSのユビキタス言語の語彙に含まれます。そして、そうであるなら、この語の意味のこうした違いは、その2つのVCSの基礎を成すドメインモデルの違いを反映しているのに他ならないでしょう。

この例から、これらの2つのモデル間の違いは、同一のドメインの問題を解決するためのアプローチの違いに由来することが分かります。ドメインモデルはドメイン自体のモデルではありません。そうではなく、実のところそれは、そのドメインのためのソリューションのモデルです。それぞれのVCSが誕生して初めて、それぞれのモデルが認識されるようになったのです。

このアイデアは全く単純明快です。別の例として、スプレッドシートソフトを見てみましょう。各種のスプレッドシートソフトは、シート、セル、数式、等々で構成される独特なドメインモデルを共有しています。このドメインモデルは VisiCalc とともに誕生し、その後進化してきたものです。私たちは会計の計算のためにスプレッドシートソフトを使うかもしれませんが、会計ドメインが、その歴史においてスプレッドシートの概念を持っていたわけではありません。そうではなく、スプレッドシートの概念やモデルは、幅広いドメインの問題を解決するために設計され、そのドメインが会計の一部をたまたま含んでいた、ということなのです。

2つのドメインモデル

伝統的に、ドメインモデルは、「分析モデル」と見られる傾向にあります。すなわち、設計ではなく分析の対象です。しかしながら、ドメインモデルはソリューションのモデルであるという私たちの新しいビジョンは、この見方に異議を唱えます。「ソリューション」が何であれ、それは私たちが設計するものです。折に触れて私たちが既存のソリューションの設計を分析するにしても。

「設計」は、以前に存在しなかったものを創造するのに対して、「分析」は、それがすでに存在する物事を扱うという点で、いくぶん受動的な言葉です。伝統的なOOアプローチにおいては、分析モデルは、既に存在し、当然の帰結として設計の対象ではない現実世界の抽象として見られる一方、私たちが（エンジニアとして）構築するソフトウェアの機能と構造を決定することを「設計」と呼ぶ傾向があります。エンジニアリング視点からは、この分割はとても自然にみえます。

ここでのポイントは、ドメイン駆動設計者の視点からは、「現実世界」は2つの下位要素―物理的な要素と情報の要素―を含むであろう、ということです。

物理的な世界にあっては、人々が働き、モノが動き、お金が稼がれます。それらは私たちが「ビジネス」という言葉によって想像するものです。ビジネスを進めるために、注文、請求、在庫記録、財務諸表、等々といった情報を私たちは記録し交換します。これは現実世界のもう1つの構成要素―情報処理―です。

したがって、ドメインモデルは2つの異なったモデルに分割されます。物理世界のモデルと情報のモデルです。

このような世界観のもとでは、物理世界のモデルはたいてい単に与えられ我々にとって制御できないものであるのに対して、情報のモデルの大部分は我々が設計し得る、と私たちは考えるでしょう。

2つのドメインモデルとOOA

DDD本において、エヴァンスは初期時点での表面的なモデルと深いモデルについて繰り返し語ります。コンテナ輸送アプリケーションからの彼の事例では、表面的なモデルが船舶（Ships）やコンテナ（Containers）のような物理的な実体を含んでいるのに対して、深いモデルは本船名／航海番号（Vessel Voyages）や船荷証券（Bills of Lading）（例えば p.191 「深いモデル」）のような抽象概念を含んでいます。これらのモデルの間の区別は、少なくとも部分的には「深さ」の違いによるのではなく、「対象」の違い、すなわち、対象が物理的なものか情報か、によるのです。

エヴァンスは、伝統的なOOAがこの区別を無視する様子に関して、示唆的な話を語ります。

新しいオブジェクトモデラがプロジェクトに参加すると、決まって最初に提案するものがあった。それが、あるはずのクラス、船舶とコンテナである。彼らが聡明でなかったわけではなく、ただ、深いモデルを発見するためのプロセスを経験していなかっただけなのだ。
（p.192）

2つのドメインモデルという着想に照らして、私たちは、これは「ただ、深いモデルを発見するためのプロセスを経験していなかっただけなのだ」ということだけによるのではなく、OOAの知識体系（または少なくともその一般的に受け入れられた理解）が物理的な世界のモデルと情報のモデルの区別を欠いているからであろう、と理解することができます。

しかしながら、この区別が無視されているといって驚くには当たりません。なぜなら、この2つのモデルの区別は常に明らかであるとは限らないからです。というのも、情報は、私たちの世界のあらゆる領域に浸潤してしまっており、あたかも物理的存在であるかのような顔をしてまかり通っているからです。小切手は物理的でしょうか？あるいは情報でしょうか？私たちはどのように真に物理的なものと小切手を区別するのでしょうか？あるいは、そもそも区別しなければならないのでしょうか？この点について私は明快な答えを持っていません。多くの場合、あなたは（まるでそれらが物理的であるかのように）情報モデルから安全に小切手を除外することができますが、その一方で、（紙幣、硬貨、小切手をひっくるめて呼ぶ）「現金有高（げんきんありだか）」をモデルに含めなければならないかもしれません。しかし、これは金科玉条ではありません。私たちは自身の判断力を用いなければなりません。とはいえ、物理的なモデルと情報のモデルの間に線を引くことは、依然としてモデリングにおける洞察をもたらすことができるでしょう。なぜなら、最終的に私たちがソフトウェアによって表現しなければならないものは、物理的なビジネスのモデルではなく情報のモデルだからです。

DDDの含意

ユビキタス言語とモデル駆動設計はDDDの中核を成す2つのプラクティスです。2つのドメインモデルに照らすと、ユビキタス言語は、物理的な世界のモデルから情報のモデルを切り離すための、そして後者を分析ではなく設計の対象とするための仕掛けとして理解することができるでしょう。それは、私たち開発者の領域を広げます。そしてモデル駆動設計は、ソフトウェアの構造が情報のモデルを正確に反映している状態を保ち続けることを私たちに要請します。それは、私たちの職業がアナリストと開発者に分解することを防ぎます。

かくして、情報モデルの設計は私たちの手の内にあります。私たちの情報技術の時代以前においてさえ、情報モデルは設計されてきました。複式簿記は、それらのモデルの注目に値する実例です。列車運行図表（ダイヤグラム）や楽譜はその他の例です。これらのモデルは、「ビジネス側」の人々によって設計されてきました（その頃「IT側」は存在しなかったので）。対照的に、私たちのIT時代において、情報モデルを設計する責任は宙に浮いているかのようです。私たちのITは、ビジネス側の人々にとってとても付き合いにくいものです。それゆえ、彼らは、ITを使って実装される情報モデルの設計にしばしば苦痛を感じさせられてきました。アナリストが設計の責任を担うべきなのかもしれません。しかし、彼らが行うのは設計ではなく分析です。その上、実装がもたらすであろうフィードバックを受けることができない中で設計するのは困難です（これもまたモデル駆動設計が重視する点です）。私たち開発者は、この責任を引き受けるベストな位置にいるのです。もちろん、ビジネス側の人々との緊密な協力関係を前提として。

ならば今、私たちの職業の本質的な営為のひとつは、ソフトウェア設計に裏打ちされた情報設計であるわけです。
これがDDDの含意です。

杉本 啓 @sugimoto_kei
経営管理基盤ソフトウェア fusion_place の、プログラマ兼設計者
http://www.fusions.co.jp

2015年4月25日に大阪で開催された関西IT勉強宴会で、DDDのモデリングについて発表しました。

• 第40回IT勉強宴会【DDD,UML,DOA競演モデリング発表会２】
• DDD,UML,DOA競演モデリング発表会２＜第40回IT勉強宴会in大阪＞ - ＩＴ勉強宴会blog
• 発表の録画（YouTube）
• モデリングの標準問題から学べること: 設計者の発言

発表で利用したスライドと、実装したコードのリポジトリリンクは以下です。

• phpmentors-jp/flower-shop

当日の内容については、togetterのまとめをご参照ください。

今回この勉強会で私の現時点のDDDについて発表する機会ができたのは、とてもよかったです。モデリングという視点と経験の豊富な方々のあつまる勉強会で、いろいろなフィードバックも頂けてとても貴重でした。

また、昨日は私を含めて3つの発表があったわけですが、井田さんの問題設定とアプローチや話の組み立て方などものすごく勉強になりますし、TH法の堀越さん、石井さんの話でも使い込んできたパターンの形などとても納得感がありました。井田さん、堀越さん、石井さん、ありがとうございました。

そして毎度このような勉強会の開催にご尽力されている佐野さん、本当にありがとうございました。

DDDのリポジトリがORMコンポーネントへ依存することの是非について、オブジェクト指向の原則の面から解説します。

リポジトリ（repository）とは、収納場所・倉庫・貯蔵庫を表す言葉です。

DDD（ドメイン駆動設計）では、リポジトリはモデル駆動設計でドメインをモデリングする際のビルディングブロックの1つになっています。ビルディングブロックとは基本構成要素のことで、ドメインをモデリングする際の基本部品として使います。

DDDのリポジトリの役目は、ドメインレイヤーのオブジェクトから永続化レイヤーを隠蔽することです。リポジトリ＝"エンティティの貯蔵庫"という抽象化されたオブジェクトを持ち込み、ドメインレイヤーの内部では貯蔵庫からエンティティを取り出すように設計・実装します。

構築するシステム（ここでは何か１つのシステムのみをイメージしてください）においてアーキテクチャが決定すると、その段階では永続化レイヤーに使われるコンポーネントが１つ選定されているでしょう。DDDのリポジトリは、ドメインレイヤーの中で永続化コンポーネントとのやり取りを担当します。根本的には、リポジトリは何らかの永続化コンポーネントに依存することになります。

依存関係逆転の原則

ドメインレイヤーはピュアに保つ。これがドメイン駆動設計における基本ポリシーです。しかし、外部とのやり取りを責務として持つオブジェクトについては、根本的に外部への依存を無くすことはできません。次の図のように、何らかのORMコンポーネントを利用した実装になるのは必然で、つまり依存が持ち込まれます。例えばSymfony Standard Editionの構成であれば、ORMコンポーネントにDoctrineが使われます。リポジトリは、Doctrineの提供するリポジトリ用の基底クラスであるEntityRepositoryを継承した実装になります。ドメインレイヤーの実装をドメインパッケージ、ORMはORMパッケージとしてまとめられていることを想定しています。

このように外部への依存を持ってしまった部分に対して、オブジェクト指向のクラス設計原則（SOLID原則）の1つである依存関係逆転の原則（DIP：Dependency Inversion Principle）を適用するとどうなるでしょうか。

依存関係逆転の原則では、直接依存しあう2つのクラスについて、間にインターフェイスを設け、2つのクラスそれぞれがインターフェイスに依存するように変更します。リポジトリの例では、ドメインパッケージには特定のリポジトリのインターフェイス（例：UserRepositoryInterface）のみを配置するようにします。リポジトリの実装は、ドメインパッケージの外に配置した実クラス（UserRepository）にて行います。このクラスが、ドメインパッケージにあるインターフェイスを実装し、ORMコンポーネントの基底クラスを継承します。こうすることで、リポジトリの実装をドメインパッケージの外に出すことはできました。

それでは、ドメインパッケージの外に出たリポジトリの実装は、どこに属するのでしょうか？

リポジトリの実装は、リポジトリパッケージに配置することにします。このパッケージはドメインパッケージから依存関係の理由で分割したというだけであり、依然としてドメインレイヤーに属するものだということに注意してください。リポジトリパッケージを切り離したドメインパッケージは、外部依存を持たなくなり、凝集度が高くなっています。

再利用・リリース等価の原則

しかし、ドメインレイヤーのオブジェクトは、それぞれ変更されていく可能性が高いものです。リポジトリの持つメソッドを追加したいということも出てくるでしょう。この場合、ドメインパッケージに属するリポジトリのインターフェイスと、リポジトリパッケージに属するリポジトリ実クラスの両方を修正しなくてはなりません。つまり、個別のリポジトリのインターフェイスというのは不安定（＝変更が発生しやすい）なものだったわけです。不安定なものを抽象化することは、無理やり安定させようとするため矛盾・ひずみを生みます。結局ドメインの問題についての変更要求でドメインパッケージとリポジトリパッケージの両方に変更を加え、両方を同時にリリースするようになるでしょう。したがって、再利用・リリース等価の原則（REP：Reuse-Release Equivalency Principle）と照らしあわせても、これらは１つのパッケージにある方が自然と言えます。

また、現実のプロジェクトでは、リポジトリの操作には特定の汎用知識（問い合わせ方法）が必要になるでしょう。この用語をリポジトリごと・プロジェクトごとに再定義するのは手間であり、また、多くの場合この問い合わせ言語はドメインの本質部分ではありません。ORMの提供する問い合わせ用メソッドを「問い合わせドメインの言語」として自ドメインに輸入してしまうのが現実的です。

Doctrineの提供するリポジトリ基底クラス（EntityRepository）のインターフェイスが安定しているということも前提になります。

まとめ

DDDのリポジトリとORMコンポーネントの関係に着目して依存について解説しました。依存の排除に固執しすぎると、本来注力すべき部分から外れてしまう場合があります。パッケージの安定度を見極め、それに合わせた抽象化にとどめておくことで、「変更しやすさ」を維持していくことが肝要です。

参考

パッケージの安定度・不安定度といった尺度については、Robert C. Martin著『アジャイルソフトウェア開発の奥義 第2版』20.5.1「安定性」、20.5.2「安定性の尺度（目安）」を参照してください。

• Robert C. Martin - Dependency Inversion Principle(PDF)
• (山口 大輔氏による翻訳)
• DIP：Dependency Inversion Principle - BEAR Blog
• PHP ソフトウェアメトリック - BEAR Blog
• PHPメンターズ流 設計と実装の型

ドメイン駆動設計の「モデルの深さ」などについての考察、前回の続きです。

• Practical DDD #2: 責務のレイヤーとPolicy-Control-Operation

前回の記事では、エリック・エヴァンスのドメイン駆動設計で書かれているモデルの深さというのは分かりづらいので、別の尺度としてモデルに表れる概念群の凝集度を考えてみてはどうか、ということに触れました。また、ユビキタス言語にあらわれる概念と概念が互いに関連しあい、述語でつながっていれば、パターンランゲージのようにドメインの知識を豊かに伝えることができるでしょう。

今回はドメイン駆動設計第1章の最後のストーリーで到達した「船荷証券（ふなにしょうけん）」というものから、モデルの深さについて考えてみます。

そもそも海運ドメインについて

私には海運ドメインについての知識がありません。エヴァンス氏自身がそうだったのかはさておき、ドメイン駆動設計のストーリーとしても、プロジェクトの初期において開発者には海運ドメインについての深い知識はないという想定になっています。しかし、ドメインモデリングを行うには対象ドメインの知識が必要です。エリック・エヴァンスのドメイン駆動設計では、ドメイン知識を得る方法としてドメインエキスパートとのコミュニケーションが中心的に取り上げられていますが、対象ドメインについての知識を得る方法は他にもたくさんあります。『ドメイン分析・モデリング―これからのソフトウェア開発・再利用基幹技術』には、ドメイン分析に使う情報として、次の項目が例示されています。

• 目的業務
• 業務マニュアル
• そのドメインの教科書、パンフレット、用語集
• ドメインエキスパートへのインタビュー
• ビジネスの現状
• ドメインの境界、スコープ、近隣ドメイン
• 使用可能なテクノロジ
• D-AMEの適用範囲
• 開発事例
• 既存のシステム（パッケージ）
• 既存のシステムの開発担当者へのインタビュー
• 既存の仕様書、マニュアル
• 実現プラットフォーム
• ひな形アーキテクチャ
• 法規
• コスト制約

(D-AMEというのは、「ドメイン分析・モデリング」で紹介されているドメイン中心の分析・設計・開発スタイルの名称です。Domain Analysis, Modeling and Engineeringの頭字語)

ドメインエキスパートへ素朴にヒアリングするわけではなく、事前に様々な知識を揃えておけということで、これは当たり前のことですね。このリストを見ると、自社サービスやいわゆる業務システム以外のシステムを開発する場合も例外ではなく、ドメイン知識を得るための材料はたくさんあるということが分かります。最近ではWebで検索することでかなり手軽に仕入れられる情報も増えていますね。

• 海運 - Wikipedia
• 船荷証券 - Wikipedia

JETRO（日本貿易振興機構）のページのFAQで「船荷証券」について調べると49件もありました。

• 検索結果 - 貿易・投資相談Q&A - 国・地域別情報（J-FILE） - 海外ビジネス情報 - ジェトロ

また、実際に海運関係のお仕事をされていた方のホームページも見つかり、次の図のように端的に海運業を表すモデルも示されていました。

• 港のお仕事 - われら海族

• B/L(Bill of lading) 船荷証券
• L/C(Letter of Credit) 信用状
• L/G(Letter of Guaranty) 保証状
• S/O(Shipping Order) 船積指図書
• M/R(Mate Receipt) 本船受領書
• D/O(Delivery Order) 荷渡指図書

われら海族のページには、上の図が基本の流れと説明されています。

これらの情報から推察すると、少なくとも船荷証券という知識は、ドメインエキスパートへのインタビュー初日から出てきそうなくらい、海運ドメインでは基本中の基本になっているように思えます。

船荷証券は「深い概念」なのか？

ドメイン駆動設計の第1章の最後に、ドメイン駆動設計のハイライトである深いモデルの話があります。

結局、何ヶ月も知識をかみ砕いた後で我々が気づいたのは、貨物の取り扱い、すなわち物理的な荷積みと荷下ろしや、ある場所から別の場所への移動などは、ほとんど下請け会社や社内の業務担当者によって行われているということだった。輸送業エキスパートから見れば、関係者の間で連続して責任が移動するということだったのだ。（中略）重要視されるようになったのは、輸送日程の手配よりも、船荷証券などの法律書類や支払い免除につながるプロセスだったのだ。
エリック・エヴァンスのドメイン駆動設計
第1章 知識をかみ砕く 深いモデル (p. 21)

この文章からは「船荷証券などの法律書類や支払い免除につながるプロセス」が深いモデルである、ということのように読めてしまう気がしますが、果たしてそういうことなのでしょうか？

船荷証券自体は海運ドメインでは当たり前の知識で、実際に業務担当者は「現物」として印刷された船荷証券をやりとりしているかもしれません。モデルを蒸留し、考えに考えて絞り出された抽象、という類のものではなく、素朴に現実として存在し使われているものです。つまり、船荷証券自体は深い概念ではないというのが現在の私の解釈です。
（この考えに至る過程で、IT勉強宴会の方々からのアドバイスが大変参考になりました。ありがとうございます。）

では、ドメイン駆動設計で語られているこのストーリーは間違っているのかというと、そういうことでもありません。このストーリーの「続き」が書籍のあちこちに出てきますが、まさに「深いモデル」そのものについて説明されている第15章 蒸留のうち「隔離されたコア」にある例15.4 (p. 436〜) などからは、深さを見て取れます。（p. 440 にある 図 15.4 隔離されたコアの完成後に非コアサブドメインの有意義なモジュール化が続く、から抜粋しています）

ここには船荷証券などとともに「顧客合意」という抽象要素が追加されています。この要素によって、配送ドメインから顧客にまつわる関心事が分離され、配送ドメインがより凝集されていることが分かります。このパッケージの中を眺めると、顧客合意のみ抽象度が高く、抽象度という軸では統一されていませんが、この点は問題ではないということですね。蒸留された深いモデル、そしてそれを表すモジュール／パッケージというのは、抽象度の高い要素のみで構成されているわけではなく、パッケージの目的にふさわしい抽象度で、過不足無く要素がつまったものなんでしょうね。この意味では、パッケージ分割のために適切な抽象要素を見つけることと同じか、あるいはそれ以上に、適切なパッケージ名を見つけることもとても重要なのでしょう（15章の例では、輸送から、配送／顧客／物流に分割されています。）。

凝集度の高さがモデルの深さと1対1に対応するわけではありませんが、凝集度を高めることは、深いモデルであるための必要条件とはいえそうです。

船荷証券にもっと早く気付くには

ドメイン駆動設計の蒸留で説明されているような深さのあるモデルは、確かに一朝一夕には辿り着けないかもしれません。「顧客合意」のようにパッケージを分割できるような役に立つ抽象は、ドメインエキスパートも明確には概念化していないでしょう。開発者がモデルの凝集度を高めることを考えていく過程で、見つかるものというのも納得できます。

一方、船荷証券のような業務で基本的に扱っているモノについては、気づくまでに何ヶ月もかけていては話になりません。船荷証券に着目していなかったモデリングは、対象ドメインという大枠ではズレていなかったとしても、やはり何かズレた対象／異なる層をモデリングしてしまっていたと言わざるを得ません。ここを見誤らないようにするためには、管理過程から業務過程を見る、または帳簿組織に着目するという視点が役に立ちそうです。これらについては、また次回。

追記

@sugimoto_kei氏より次のご指摘を頂きました。

船荷証券(B/L)を含む貿易取引の仕組み自体は「深い」ですよ。歴史の中で洗練されてきたモデルだし。でも、取引で用いるそうした記録のモデルと、貨物や船舶といった「現実のモノ」を対象にしたモデルの違いは、「深さ」とは別の軸上にあるのですね。

本文で「船荷証券は深い概念ではない」と書きましたが、これは「対象をモデリングした結果として表れるもの」という括りで見れば、ということです。杉本さんの仰るとおり、この海運ドメインは歴史があり、それ自体が深く洗練されているのですね。しかしそのことと、開発するシステムにおいて「深く蒸留されたモデル」を作り出すこととは、別の軸の話であるということです。

書籍「実践ドメイン駆動設計 (Object Oriented Selection)」が出版されて、ドメイン駆動設計（DDD）の知名度が上がってきているようです。

そのDDDに関連する分野の１つとして、DSL（ドメイン特化言語）を挙げることができると思います。

デバシッシュ・ゴーシュさん（Debasish Ghosh）は、DSLのエキスパートで、「実践プログラミングDSL」（原題 “DSLs in Action"）という本を出されています。この本の第１章のタイトルは、「ドメインの言葉を話す方法を学ぶ」となっています。

デバシッシュさんのブログ記事のうちの１つ、"Functional Patterns in Domain Modeling - The Specification Pattern” に惹かれて、翻訳をしました。翻訳記事の公開について、著者ご本人から快諾頂けたため、以下に掲載させて頂きます。

ドメインモデリングにおける関数型パターン―仕様パターン

原文URL：http://debasishg.blogspot.in/2014/03/functional-patterns-in-domain-modeling.html

2014年3月31日月曜

ドメインをモデリングするときは、ドメインのエンティティと振る舞いをモデル化する。エリック・エヴァンスが書籍「ドメイン駆動設計」で述べたように、焦点を合わせるべきはドメインそれ自体だ。設計、実装したモデルは、ユビキタス言語を語っていなければならない。実装にの都合により、偶有的な複雑性が多々生じても、ドメインの本質を捉えることができるようにするためだ。表現力の豊かなモデルにするには、拡張可能であることも必要である。そして、私たちが拡張性について語るとき、関連する性質として合成性がある。

関数は、オブジェクトよりも自然に合成を行う。そこで、この記事では、ドメイン駆動設計のコアを成すパターンのうちの１つを実装するために、関数型プログラミングのイディオムを用いるー 仕様パターンだ。 仕様パターンで最も多いユースケースは、ドメインのバリデーションを実装することである。エリックのDDD本には、仕様パターンについて次のように書かれている：

仕様の用途は複数あるが、最も基本的な概念を伝えているのは、どんなオブジェクトでも評価して、定義された基準を満たしているかどうかを調べるという使い方である。

仕様は述語として定義され、それによって、業務ルール同士をブール論理を使って互いに連鎖させて結合できるようになる。このように合成の概念があるので、このパターンについて語るときは合成仕様（Composite Specification）として語ることができるだろう。DDDにおける各種の文献では、これをCompositeデザインパターンを使って実装しており、ごく一般的にはクラス階層とコンポジションが用いられていた。この記事では、その代わりに関数合成を使う。

仕様はどこにあるのか？

モデルを設計する際によくある問題として、集約ルートやエンティティのバリデーションを行うコードをどこに置くのか、という話がある。

• エンティティの中でバリデーションをするか？ これはダメだ。エンティティが肥大化してしまう。同じエンティティのコアでも、コンテキストによってバリデーションを変えたいことがある。
• インターフェイスの一部としてバリデーションをするか？ JSONを使って、その外側でエンティティを構築するかもしれない。たしかに、ある種のバリデーションはインターフェイスに属すると言えるし、そこにバリデーションを置くことに違和感は無い。
• しかし、もっとも興味深いバリデーションは、ドメインレイヤーに属するものだ。業務のバリデーション（あるいは仕様）であり、エリック・エヴァンスが他のオブジェクトの状態に関する制約をのべるものと定義している。 業務ルールとして、エンティティを次の処理へ渡す前にバリデーションをかけなければならない。

単純な例で考えよう。注文（Order）エンティティとそのモデルがあるとする。新しい注文は、処理工程に入る前に、下記のドメインの「仕様」を満たすものとする。

1. 妥当（valid）な注文でなければならず、ドメインが必要とする正当な日付、正当な商品品目、といった制約に従わなければならない。
2. 正しい権限で承認（approved）されていなければならない。処理工程の次段階に進めるのはその場合だけだ。
3. 顧客がブラックリストに載っていないことを保証するため、状態を審査しなければならない。
4. 注文可能かどうかを調べるため、商品品目の在庫を確認しなければならない。

個々の手順に分かれていて、注文の処理工程に沿って順次完了していく。そのようにして、注文の前に、注文実行の用意が整っているどうかを検証する。どこかでエラーがあると、注文は処理工程から外れて、そこで処理が終わる。そして、私たちが設計するモデルは、この順序を知っている必要があるし、手順の一部として経るべき制約はすべて課す必要がある。

注文を変化させるのは手順だけである―ここは重要なポイントだ。すべての仕様は、最初の注文のコピーを入力として受け取り、ドメインルールを検証後、処理工程の次の手順へ進ませて良いかどうか判定する。

実装へ……

私たちがここまでで学んできたことをふまえて、実装に落としこんでみよう。

• 注文は、少なくとも今回の操作の流れにおいては、不変のエンティティにできる。
• すべての仕様は１つの注文を必要とする。これがトリックになっていて、仕様に注文インスタンスを順次渡すことで、APIをシンプルに保つことができる。
• 関数型プログラミングの原則により、上記の処理手順を式としてどのようにモデル化できるか。結果を最後まで合成可能に保ち、注文完了後の次工程へ渡すにはどうするか（次工程については、いずれまた別の記事で議論しよう）。
• すべての関数は似たシグネチャを持っているようだ―私たちは関数をたがいに合成する必要がある。

あれこれと説明や理論を持ち出すよりも、まずは基本的なビルディングブロックを使ってドメインエキスパートととりまとめた内容を実装していこう。

type ValidationStatus[S] = \/[String, S]

type ReaderTStatus[A, S] = ReaderT[ValidationStatus, A, S]

object ReaderTStatus extends KleisliInstances with KleisliFunctions {
  def apply[A, S](f: A => ValidationStatus[S]): ReaderTStatus[A, S] = kleisli(f)
}

ValidationStatusは、どの関数からも結果として返す型を定義している。それは状態S、または何らかの異常を報告するエラー文字列となる。正確にはscalazで実装されているEither型（右側が正）である。

この実装が優れているのは、すべてのメソッドで注文パラメータが繰り返されることなく処理手順が呼び出されるからだ。そのようにするイディオムの１つとして、Readerモナドが使われる。そして、私たちはすでにモナド―\/はモナドだ―を持っている。そこで、処理結果をモナド変換子を使って積み上げていく。ReaderTがこの作業を受け持つ。結果同士を結びつけてくれるありがたい型としてReaderTStatusを定義する。

次のステップはReaderTStatusの実装で、クライスリと呼ばれる別の抽象を使う。scalazライブラリを使って、クライスリの言葉でReaderTを実装する。実装の詳細に立ち入る話はしないでおく―もし興味があるのであれば、ユージーンによる優れた論文を参照してほしい。

さて、サンプルの仕様はどのようになるのか？

話に入る前に、基本的な抽象を用意する（わかりやすさのため、ごく単純にしてある）。

// 基底の抽象
sealed trait Item {
  def itemCode: String
}

// サンプル実装
case class ItemA(itemCode: String, desc: Option[String],
  minPurchaseUnit: Int) extends Item
case class ItemB(itemCode: String, desc: Option[String],
  nutritionInfo: String) extends Item

case class LineItem(item: Item, quantity: Int)

case class Customer(custId: String, name: String, category: Int)

// 注文のスケルトン
case class Order(orderNo: String, orderDate: Date, customer: Customer,
  lineItems: List[LineItem])

そして、下記が注文オブジェクトの制約を検査する仕様である。

// 基本的なバリデーション
private def validate = ReaderTStatus[Order, Boolean] {order =>
  if (order.lineItems isEmpty) left(s"Validation failed for order $order")
  else right(true)
}

これは説明用の例に過ぎないので、ドメインルールが多く含まれているわけではない。 重要なのは、関数を実装するために定義した型をどう使っているかだ。 注文は関数に対する暗黙の引数ではない―それはカリー化される。関数はReaderTStatusを返す。ReaderTStatus自体はモナドである。したがって、別の仕様と併せて処理工程を手順化していくことができる。つまり、決められた順序の要求を、式指向プログラミングの枠組みの中で解決できるのだ。

収集したドメイン知識に基づく仕様はほかにもあった。

private def approve = ReaderTStatus[Order, Boolean] {order =>
  right(true)
}

private def checkCustomerStatus(customer: Customer) = ReaderTStatus[Order, Boolean] {order =>
  right(true)
}

private def checkInventory = ReaderTStatus[Order, Boolean] {order =>
  right(true)
}

これらを互いにつなぐこと

しかし、ドメインが与える操作順序を表すには、これらのピースをどうつなげば良いのだろう。モデルで合成性による利点を享受するにはどうするのか？ これは非常に簡単だ。合成に適した型定義という難しい仕事はすでに終わっている。

以下のisReadyForFulfilmentメソッドでは「合成仕様」を定義していて、for内包表記（for-comprehension）でくるまれた個々の仕様すべてを順番に呼び出している。

def isReadyForFulfilment(order: Order) = {
  val s = for {
    _ <- validate
    _ <- approve
    _ <- checkCustomerStatus(order.customer)
    c <- checkInventory
  } yield c
  s(order)
}

このように、モナディックな結合により、順序立てられた一連の処理を、抽象の合成性を保ちつつ実装することができる。次回は、注文の後工程を合成可能にする方法、エンティティの情報を読むだけでなく可変とするやり方についても見ていこう。もちろん、関数型のアプローチで。

翻訳後記

この記事は、初学者の私が、背伸びをして勉強しながら訳したものです。推敲を重ねましたが、誤訳等が含まれている可能性はあります。もし何かありましたら、ご指摘頂けると幸いです。

関連記事

• Practical DDD #1: Specificationパターンの例
• ドメインモデルのための型「Domain Kata」を使ってみました

参考

• Modegramming Style: Scala Tips / Validation (10) - applicative
• 実務者のためのかんたんScalaz

Domain-Driven Design (DDD) intersects with a broad range of the intellectual heritage in the software design discipline including object-orientation, design patterns and refactoring. And as such, it can be viewed as a synthesis of these knowledge assets tailored towards domain-oriented application software development.

Although this view is valid and productive, there could be another way of viewing accomplishment of DDD. It is the theme of this short discussion.

In this context, DDD could be thought as a quiet departure from “software design” to something we may call “information design” with a special emotional attachment.

What is a Domain Model?

But first thing first. We must have a rethink on one basic question. What is a domain model?

It sounds ridiculous. A domain model is a model of a domain. Isn’t it?

Let us discuss about this on a concrete example: version control systems (VCSs). We now have a bunch of VCSs, each of which offers a somewhat different model than another. For instance, with Subversion, “commit” means a registration of source code changes to the central (and solitary) repository, whereas, with Git, the same word means a registration of source code changes to a particular member of a set of distributed repositories. “Commit” is in the vocabulary of ubiquitous language of each VCS. And if so, this difference in the meaning should be the reflection of a difference of the underlying domain models of the two VCSs.

From this example, we can see that the difference between these two models comes from the difference in approach to solve problems in the same domain. A domain model is not a model of a domain itself. Instead, it actually is a model of a solution for the domain. It was not before each VCS was given birth that each model was recognized.

This idea is quite simple and straightforward. Let us take spreadsheet software as another example. They share a unique domain model consisting of sheets, cells, formula and so on. This domain model did not exist before the birth of VisiCalc and evolved after that. Although we may use spreadsheets for our accounting calculation, it is not that accounting domain had the spreadsheet concept in its history, but the concept and model were engineered to solve problems in a broad domain, which incidentally includes a part of accounting.

Two Domain Models

Traditionally, domain models tend to be seen as “analysis models”, which are subjects of analysis, not design. However, our new vision that a domain model is a model of a solution challenges this view. A solution is something we design, even if we analyze designs of the existing solutions from time to time.

“Analysis” is rather a passive word in that it treats things which already exist, while a design creates something that did not exist before. In traditional OO approaches, an analysis model tend to be viewed as an abstraction of the real world, which already exists and naturally is not a subject of design, while a design governs the functionalities and the structures of software we (as engineers) build. From the engineering perspective, this separation looks very natural.

The point here is that from a domain-driven designer’s perspective, a “real world” would consist of two subcomponents - physical and informational.

In the physical world, people work, things move, and money is earned. They are what we imagine by the word “business”. To let businesses move on, we record and exchange information - orders, invoices, inventory records, financial statements, and so on. This is another component of the real world - information processing.

Accordingly, a domain model is divided into two distinct models: physical world models and informational models.

With such a world view, we would consider the physical world models as usually just given and uncontrollable for us, while we can design most parts of the informational models.

Two Domain Models and OOA

In his DDD book, Evans repeatedly speaks about initial superficial models and deep models. In his example from a container shipping application, the superficial model contains physical entities like Ships and Containers, while the deep model contains such abstract concepts as Vessel Voyages and Bills of Lading (e.g. p.189 “Deep Models”). The distinction between these models is at least partially not of the “depth” but of the “subject” of each model - physical and informational.

Evans tells a story which is suggestive on how traditional OOA ignores this distinction:

Whenever new object modelers showed up on the project, what was their first suggestion? The missing classes: ship and container. They were smart people. They just hadn’t gone through the processes of discovery.
(p.190)

With the idea of two domain models, we understand this would not have been only because “they just hadn’t gone through the processes of discovery”, but also because the body of knowledge of OOA (or at least its generally accepted understanding) has lacked the distinction of physical world models and informational models.

However, this ignorance is not surprising, because the distinction between the two models is not always apparent. It is because information has infiltrated into every corner of our world and passes as if they were physical. Are bank checks physical or informational? How do we distinguish them from truly physical objects? Or, do we have to do so at all? I have no definitive answer here. In many cases you can safely omit checks from your informational models (as if they were physical), while you might have to include “cash in hand” in your models (which refers to bank bills, coins, and checks, collectively) instead. But it is not a dogma. We have to use our judgment. Nevertheless, drawing a line between physical and informational models could still bring insights in modeling, because in the end what we have to represent with our software are informational models, not physical business models.

An Implication of DDD

Ubiquitous language and model-driven design are two practices at the heart of DDD. In the light of two domain models, ubiquitous language could be understood as a device to separate an informational model from a physical world model and make it subject of design, not analysis. It extends the realm of us, developers. And model-driven design urges us to keep software structure to be exact reflection of the informational model. It prevents our profession from dissolving into analysts and developers.

Thus, design of informational models is in our hands. Informational models had been designed even before our information technology age. Double-entry book-keeping system is a remarkable instance of those models. Train operation diagrams and music scores are other examples. These models had been designed by people on the “business-side” (because there was no IT-side). By contrast, the responsibility to design informational models seems to be floating in our IT age. Our IT has been too awkward for business people. Therefore they often have felt uncomfortable designing informational models which are to be implemented with IT. Analysts might be the people in charge. But they analyze, do not design. Furthermore, it is difficult to design if you are disconnected from feedbacks that implementation would provide (this is also what model-driven design cares). We, developers are in the best position to accept this responsibility, off course with a tight cooperation with business-side people.

Now an essential act of our profession is the information design underpinned by the software design.
This is what DDD implies.

Kei Sugimoto @sugimoto_kei
Programmer and Designer of fusion_place, a management infrastructure software
http://www.fusions.co.jp

2014年4月6日に大阪で開催された第4回ドメイン駆動設計読書会＠大阪に参加しました。読書会の内容のまとめなどはWikiの方をご参照ください。今回は第1章の知識のかみ砕き、深いモデルと第2章ユビキタス言語の前半を読み、ディスカッションしました。ディスカッションで得られた気付きとこれまでに私が考えていたこと、ドメイン駆動設計の後半に出てくる「責務のレイヤー」などとのつながりについて、考察してみます。

モデルの「深さ」とは何か

モデルに対して深いのか浅いのかについて、ドメイン駆動設計で何か客観的な指標が示されているわけではありません。あくまでエヴァンス氏の主観でしかないと言えますし、開発者が取り組んでいるドメインやコンテキストに依存するものでもあります。ドメイン駆動設計においては、モデルの深さを探求していくことが大きな目標の1つとされており、「深いモデル」という言葉が開発者同士の共通語になってはいます。しかし、もう少しブレの無い言葉で表現しておいた方が良いように思います。ここで、ソフトウェア工学で使われてきた「凝集度」という言葉を使えば、「概念群の凝集度」という視点で置き換えられるのではないかと私は考えます。この捉え方はすでに増田亨さんのブログでも触れられています。ドメイン駆動設計の後半では、蒸留カテゴリの中に凝集は繰り返し現れます。

• 凝集度を高める：クラスもパッケージもコンテキストも「ドメインの視点」で凝集すべし | システム設計日記

ユビキタス言語で凝集度を判定する

内容の順序と前後しますが、ユビキタス言語の章では2つのシナリオが例示さています。分かりやすい箇所を抜粋します。

開発者：わかりました。該当する貨物IDを持ったすべての行を輸送テーブルから削除してから、荷受け地と荷出し地、新しい通関地点を経路選択サービスに渡せば、テーブルにデータが再登録されます。貨物にブール値を持たせて、貨物テーブルにデータがあることがわかるようにしましょう。

開発者：わかりました。経路仕様にある属性をどれか1つでも変更したら、古い輸送日程を削除した上で、経路選択サービスに対して、新しい経路仕様に基づいた新しい輸送日程を生成するよう依頼します。

シナリオ 1 では、ユビキタス言語由来の単語は2つですが、シナリオ 2 では3つになっています（この箇所では貨物は出てこなくなっています）。そして、伝えたい意図を表現するための語彙のセットに変化しています。シナリオ 1 では、概念凝集度の低いモデルの表象としてのユビキタス言語をベースに開発者が意図を話そうとしているわけですが、この発言をしながら開発者自身「語彙が足りない」ことに気づくのではないでしょうか。言うならば、初めての海外旅行先で英語を話そうとしても、言いたいことが言えないという感覚と同じです。みなさんもモデリングセッションの中で少なからず体験されていることと思います。

ユビキタス言語が凝集されていない状態：

凝集度の高いユビキタス言語：

ところで、次に出てくる疑問は、どのようにしてユビキタス言語を構成しうる知識をかき集め、ドメインモデルを成長させていくのか、という点でしょう。これをエヴァンスは「知識のかみ砕き」や「蒸留」、「隠された概念を引き出す」のように表現しています。

オーバーブッキングポリシー

「隠された概念を引き出す」例として、オーバーブッキングポリシーの話が示されています。貨物輸送ドメインにおいては「オーバーブッキングの仕方」は重要な概念なので、概念として明示的にドメインモデルに登場させます。それと同時に実装コード側も、メソッド本体の if 文に埋もれた状態から1つの独立したクラスに切り出されています。

この例では、業務知識からの要請によってオーバーブッキングポリシーという概念を得ています。この程度のものであれば、業務知識がなかったとしても、コードのリファクタリングから発見できた可能性もあるでしょう。ドメイン駆動設計では実装からのフィードバックも重視されており、実装とコードのリファクタリングから何か得られるかもしれない、という心構えは常に必要です。

一方で、あらゆる対象ドメインをゼロから実直にモデリングして実装し、リファクタリングを繰り返さなければ深いモデルにたどりつけないのかという疑問が出てきます。手早く確実に「オーバーブッキングポリシー」という概念を得る方法はないのでしょうか。業務知識を豊富に持っていれば、もちろん役立つでしょう。しかし、あらゆるドメインの個別知識を持つことなどできません。ある程度汎用性のある知識、つまり知識の体系、それも一段階抽象度の高いメタレベルの知識体系が、このような問題解決に役立ちます。このようなメタレベルの知識体系としてドメイン駆動設計で取り上げられているものの1つが、第16章「大規模な構造」の中の「責務のレイヤー」です。

責務のレイヤー

責務のレイヤーがどのようなものなのかの説明は書籍を読んでいただくとして、オーバーブッキングポリシーの例を責務のレイヤーに割り当ててみると、私の理解では次のようになります（例では航海が積載量を保持していますが、能力レイヤーに該当する要素としてうっすらと船・顧客の存在を示してみました。こちらに積載量を持たせてみています）。

ただし、この責務のレイヤーというのは文字通り「責務」のレイヤーであり、下から上方向への依存がないような知識の体系ではありますが、それでもドメインのある1つの側面を取り出してレイヤー構造に表したにすぎません。実際に貨物の運送予約という業務のユースケースを想定した場合、意思決定支援／ポリシーレイヤーにある知識が当然業務で使われなければなりませんから、この段階（コンテキスト）ではレイヤーが異なるという意識は不要になります。

ここで示したように、責務のレイヤーという知識体系によって、オーバーブッキングポリシーがどのような種類の情報なのかが明確になりました。とても自然に、それぞれの情報が各レイヤーに当てはまっているように見えます。逆に、責務のレイヤー（能力／業務／意思決定支援・ポリシー）という情報の分類を開発者が最初から知っていれば、オーバーブッキングポリシーという概念に相当早くたどり着けるように思われます。

「それなら、なぜドメイン駆動設計の最初に、責務のレイヤーを説明しないんだ！」という声が聞こえてきます。私もそう思いました。

責務のレイヤーとドメイン駆動設計の関係

責務のレイヤーを最初から知っていれば、深いモデルに早くたどり着ける。これはつまり、責務のレイヤーという概念は、ドメインの知識体系そのものの一部分であるということです。エヴァンスが「ドメイン駆動設計」として本にまとめて伝えようとしているエッセンスは、ドメインの知識体系にどうアプローチしていくのかということです。ですから 、責務のレイヤーはより早く深いモデルに到達するための既存知識体系の1つ、として紹介されているだけなんでしょうね。同じように、アナリシスパターンなどが知識体系のショートカットとして紹介されています。このようなメタレベルの知識体系で役立つものは他にいくつもあります。

ところでこの責務のレイヤーという知識体系について、元をたどるとPolicy-Control-Operationという体系があることを、2月の関西IT勉強宴会に登壇された中西先生から教わりました。

Policy-Control-Operation

経営、管理、業務という3つのタイプで、これは企業や何らかの組織がある目的を持って活動する時、つまり経営活動が行なわれる時に、さまざまなレベルで表れる構造です。

この構造のうち、特に情報の種類について言及されている例が、Milt Bryce and Tim Bryce著「IRMー情報資源管理のエンジニアリング」第2章（p. 37）の表「情報が果たす役割」として挙げられています。

ドメイン駆動設計読書会の最初の回でも紹介されていたTM（T字形ER手法）の佐藤氏のページでも、事業過程・管理過程・組織過程という業務の階層の考え方が解説されており、モデリングの際の視点の決め方として重要とされています（これは遡ると20世紀初頭の管理原則の父アンリ・ファヨールの管理過程論などからの系譜です）。

長くなりましたので、続きの「船荷証券」の話は、また次回 (Practical DDD #3: モデルの深さ)。

ドメイン駆動設計が、今、世界的に盛り上がりを見せています。2016年1月には、Domain-Driven Design Europeが開催されるそうです。このイベントのスピーカー＆ワークショップ講師の１人として、Jim Coplien氏の名前が載っています。Jim Coplien氏は、日本だと、「組織パターン」の著者として、また、DCIアーキテクチャの人として有名ですが、ドメインエンジニアリングの研究者でもあります。

Eric Evans氏のDDD本は、サブタイトルが、「ソフトウェアの核心にある複雑さに立ち向かう」となっています。複雑さとは何か、それを管理する技術とは何か、古くて新しい問題です。Jim Coplien氏の著作「マルチパラダイムデザイン」では、ドメインとは何か、どのように設計を行うべきかについて書かれています（残念ながら絶版です。）

Debasish Ghosh（デバシッシュ・ゴーシュ）氏のDDDとマルチパラダイムデザインを関連付けたブログ記事「Domain Driven Design : Managing Variability」を翻訳しました。以下に掲載します。（※デバシッシュ氏は、ScalaMatsuri2016に応募されています！）。

Note Debasish Ghosh氏は書籍「実践プログラミングDSL」（原著: DSLs in Action）の著者として知られています。彼は現在Functional and Reactive Domain Modelingを執筆中です。こちらは2016年春に出版予定だそうですが、MEAPを利用して一足先に読むこともできます。

ドメイン駆動設計：可変性の管理

原文URL：http://debasishg.blogspot.jp/2006/09/domain-driven-design-managing.html

2006年9月18日（月）

Springのユーザーたちが、ドメイン駆動設計について語り始めました。彼らはきちんと取り組んでおり、良い議論をしています。2006年に行われたSpringOneでは、ドメイン駆動設計に関する3つのセッションがありました。 AOPの人として知られているRamnivas Laddad氏（最近「Interface 21」メンバーに加わりました）は、DIとAOPが、DDDの最も良いところを引き出すのに有効であること―最小限のサービス層、豊かなドメイン層、流れるようなインターフェイスについて発表しました。 「Interface 21」とGrailsで知られるSteven Devijver氏は、サービス層にある複雑性を管理するためにデザインパターンを利用することについて語り、リッチなドメインモデリングに関する議論を行いました。 レイヤー化、AOP、IoC等による関心の分離のような重要なアスペクトについて彼は強調しました。 不変性は、モデルの正当性を維持するために重要であること。 つまり、クラスはイミュータブルに作り、できるだけ外部へ漏れ出さないように制御に努めること。 実装の内部をさらけ出してはならないこと―パブリックなセッターはNGであること。 要するに、ドメインモデルは、ドメインエキスパートが話せるドメインの言語にだけ公開されているべきだということです。 インターフェイスとパブリックな契約が、ユビキタス言語を語るように作ること。 ドメインモデリング技法に関する別のセッションでは、「Interface 21」のKeith Donald氏が、ドメインの蒸留、ドメインモデルの中に獲得した知識を抽象化するためのテクニックについて話しました。 全体を通して、SpringユーザたちはDDDファンのイベントを楽しんでいるようでした！

可変性！可変性！

ドメインモデルを、柔軟に、生成的（ジェネレ―ティブ）に作るということは、モデルにおいて可変性を管理することに尽きます。 そのモデルの可変部分をうまく管理することによって、より構成しやすく、カスタマイズしやすく、柔軟にすることができるようになります。 以前の記事では、ジェネレーターとしてはたらいて基盤を提供する構成の知識について書きました。 構成の知識を最大限に活用するのがこの可変性です。 設計のアスペクト、固有の実装、ライフサイクル、スコープの決まったインスタンス、アルゴリズム、ストラテジー等は、Java / C++のコードベースの中で埋没させたくはないものなのです。

ストラテジーパターンで示すと…

ここ数年、ストラテジーパターン実装の多くのバリエーションが、モデルの可変性を管理するために使われてきたと思います。 GOFは C++ で２つのバリエーションを検討しています。 １つは、実行時ポリモーフィズムと仮想関数を使うもの、もう１つは、テンプレートとコンパイル時ポリモーフィズムを使うものです。 それぞれにメリットがあり、特定のコンテキストにある特定の問題を解決するのに用いることができます。

下記スニペットに、ストラテジーデザインパターンを実行時ポリモーフィズムで適用して、繰延利息計算（accrual calculation）ドメインプロセスを外部化するやり方を示します。

class AccrualCalculation {

    private CalculationStrategy strategy;

    // セッターインジェクション
    public void setStrategy(CalculationStrategy strategy) {
        this.strategy = strategy;
    }

    // ストラテジーへの委譲
    public BigDecimal calculate(...) {
        return strategy.calculate(...);
    }
}

interface CalculationStrategy {
    BigDecimal calculate(...);
}

class DefaultCalculationStrategy implements CalculationStrategy {
    public BigDecimal calculate(...) {
        // 実装
    }
}

// 構成の知識を通して可変性を外部化する
<bean id="calcStrategy" class="com.x.y.DefaultCalculationStrategy"/>

<bean id="accrual" class="com.x.y.AccrualCalculation">
  <property name="strategy">
    <ref bean="calcStrategy"/>
  </property>
</bean>

ジェネリクスを使って実装した同じパターンと比べてみましょう。 繰延利息計算クラスがストラテジーでパラメーター化されるように設計しています。

class AccrualCalculation<S extends CalculationStrategy> {
    private S strategy;

    // ストラテジーへの委譲
    public BigDecimal calculate(...) {
        return strategy.calculate(...);
    }
}

// 使い方
interest = new AccrualCalculation<DefaultCalculationStrategy>().calculate(...);

トレイトテクニックのelse-if-then型（この名前、いいですね！）は、C++コミュニティで使われており、拡張性を持たせつつ型レベルで可変性を管理することができます。 トレイトクラスとトレイトテンプレートは、メタプログラミング能力に秀でていただけではなくて、様々なC++アプリケーションの開発に使われてきました。 コンパイル時ストラテジーの別なバリエーションとして、Alexandrescu氏のポリシーベース設計があります。 ポリシークラスは、実装をいくつでも持つことができ、コンパイル時ストラテジーをドメインモデルにプラグインするのに最適な選択肢を提供してくれます。

ストラテジーデザインパターンは、最適な機構を提供することで、ドメインモデルにおける粗粒度の可変性をカプセル化します。 ストラテジーの実装をIoCコンテナやその他のジェネレーターへと外部化することにより、モデルがプラガブルであるようにします（構成の知識として）。

細粒度の可変性とテンプレートメソッド

テンプレートメソッドデザインパターンは、アルゴリズム、ストラテジーといった細粒度の可変性を、共通性フレームワークの範囲内でプラグインすることを目的としています。 ドメインプロセスの大きなレベルでのフローが不変である場合、モデルでこのパターンを使います。 こまごました物をカスタマイズできるように、フックをかけて外部化するわけです。 私はルールベースの大規模な金融アプリケーションをモデリングした時に、このパターンをうまく効果的に活用できました。 下記は、テンプレートメソッドデザインパターンを使って、細粒度の可変性を実装するサンプルです。 ここで、繰延利息計算アルゴリズムはfinalであり、フックの箇所は派生クラスによって追加されます。 フックは基底クラスの抽象メソッドとして管理されます。

abstract class AccrualCalculation {
    public final BigDecimal calculate(...) {
        // フック
        int days = calculateAccruedDays(...);
        if (days != 0) {
            // 不変のロジック
            } else {
            // フック
            boolean stat = isDebitAccrualAllowed(...);
            if (stat) {
                // 不変のロジック
            }
            // 不変のロジック
        }
    }

    protected abstract int calculateAccruedDays(...);
    protected abstract boolean isDebitAccrualAllowed(...);
}

負の可変性

Jim Coplien氏は、設計、分析領域において、この用語を著作マルチパラダイムデザインの中で初めて紹介しました。 共通の継承階層にまとめられるメンバー群にあるうちの一部のメンバーが、他の点においては共通であるのに、一部の点でだけは基底クラスの仮定を破壊してしまうような時、これを負の可変性と呼びます。 Cope（訳注：James O. Coplien のこと）は、負の可変性は、基礎である共通性を侵害してバリエーションのルールを壊す、ルールの例外になる、と述べています。 負の可変性を実装するためのテクニックは少なくありません。 たとえば、C++ におけるテンプレートの特殊化や、条件コンパイル等です。 ブリッジデザインパターンもこの問題をうまく扱えることが知られています。 Coplien の「マルチパラダイムデザイン」に、負の可変性について詳しく書かれています。 この師範の深い洞察をぜひ読んでみて下さい。 実務の場で、ドメインモデルが負の可変性の振る舞いを示すことはよくあります。 そのようなとき、適したパターンやイディオムを使って、正しく取り扱う必要があります。

参考文献

• マルチパラダイムデザイン（金澤典子, オブジェクトの広場2002年2月号）
• Multi-Paradigm Design(James O. Coplien, July 8, 2000)

関連記事

• Pieceの中のSymfony #3: Dependency Injectionコンポーネント―構成の知識とDIコンテナ
• 「ドメインモデリングにおける関数型パターン―仕様パターン」を翻訳しました

ドメイン駆動設計のユビキタス言語とモデルの関係性についての、個人的なメモです。

思考を図にする

書籍「エリック・エヴァンスのドメイン駆動設計」の第2章で、ユビキタス言語の語彙について説明した段落があります。

ユビキタス言語の語彙には、クラスや主要な操作の名前が含まれている。また、モデルの中で明示されたルールについて議論するための用語も含まれている。この言語は、モデルが従うべき高次の構成原理（コンテキストマップや大規模な構造など、第14章と第16章で説明するもの）に由来する用語によって補完される。そして最後は、ドメインモデルに対して一般に適用されるパターンの名前によって、この言語は強化される。

エリック・エヴァンスのドメイン駆動設計
第2章 コミュニケーションと言語の使い方 ユビキタス言語 (p. 25)

この文章が言わんとしていることを私の理解で図にしてみました。

この図は、上に挙げた段落の意味を、パターンランゲージのナビゲーションマップの図法（DDD本の見開きにあるもの）をイメージして描いたものです。あくまで上の段落からの意味だけなので、ドメイン駆動設計のある１つの側面を表しているにすぎません。ただ、こうやって図にしてみることで、私には、書き手の思考がより伝わってくるように感じました。

これは概念モデリング？

先ほど私がやったこと、それは、ドメイン駆動設計という本に書かれた内容を解釈し、それが意味していると考えられる内容を、言葉と言葉というよりもむしろ、概念と概念の関係性としてナビゲーションマップ形式の図に表しました。要するにこれは、概念モデリングそのものではないでしょうか。

(Googleで検索してみると、同じようなことをされている方はすでにいらっしゃいます ex 「読書ツールとしての概念モデリング - 反言子」)

哲学者フォーダーによれば、

文は思考を、語は概念を表わす。(Fooder 1998)

信原 幸弘、太田 紘史 編『シリーズ 新・心の哲学I 認知篇』勁草書房 2014年
第1章 概念の構造とカテゴリー化 5-1 情報原子論と文法的現象 p. 61

というように、文章で書かれたものと、その文章から概念モデリングした図とは、その根底にある思考は共通しています。

で。。。。？

ドメイン駆動設計を軸にしたソフトウェアの分析・設計では、このように見出した概念の意味にこだわります。エヴァンスの本を読んでいると、まるで、言語体系をつくり上げること自体が設計の中心であるかのように錯覚することが私にはあります（私はまだ、そういった境地ではありません）。

ただ、ソフトウェアを設計するのに、そのような意味論にこだわりすぎるのが良い結果を生むのかどうか。今の私は結論を持っていません。

ドメイン駆動設計を読んでいる皆さんが、今回挙げた私の図を見て感じた違和感でも何でも、コメントいただけると幸いです。

参考

• モデリングのスタイル：意味論と統辞論: 設計者の発言

2018年1月10日に開催された DCI Tokyo 1 に続き、2018年3月27日に DCI Tokyo 2 が開催されました。今回も James Coplien @jcoplien さんをお招きしてのトークセッションとなりました。会場は 株式会社ヴァル研究所 様に提供していただきました。

セッションは、前回同様 @remore さんと @ganchiku さんによる同時通訳とともに進められました。

今回のテーマはマルチパラダイムデザイン（Multi-Paradigm Design: MPD）の中核を成し、DCI / リーンアーキテクチャ（Lean Architecture）とも深く関係する 共通性／可変性分析 でした。

レポートは @smori1983 が担当させていただきます。

当日の様子は Coplien さんの許可を得て YouTube の DCI Tokyo 公式アカウントにて公開されています。Coplien さんのおもしろTシャツにも注目しながら、ぜひご覧ください。

• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 1 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 2 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 3 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (Part 4 of 4)
• DCI Tokyo 2- Commonality / Variability Analysis: Practical MPD by James Coplien (extra)

全体の流れ

全体の流れとしては、1980年代以降のソフトウェア開発の歴史を、主にオブジェクト指向に対する考え方の変遷を通して振り返りつつ、MPD と DCI の関係性に迫るものとなりました。

オブジェクト指向（1988）

当時は C++ の他に、テレコム業界向け言語である CHILL や、軍需産業向け言語である Ada などの言語があり、それらの言語がオブジェクト指向なのかという議論がされていました。

最終的に C++ が残ることになりますが、C++ の作者である Stroustrup 氏は、そもそも C++ をオブジェクト指向言語ではなく、マルチパラダイム言語と定義していたことに注意する必要があります。

当時考えられていたオブジェクト指向の構成要素は次の3項目でした。

1. inheritance / 継承
2. polymorphism / ポリモーフィズム
3. instantiation / インスタンス化

1994年に Coplien さんは David Weiss 氏と Robert Chi Tao Lai 氏とともに仕事をしますが、その時、共通性／可変性分析を通じて、ソフトウェアファミリの振る舞いなどを特徴づけ、当時取り組んでいたソフトウェアのための DSL(Domain Specific Language) を開発しました。開発言語は C でした。

この、共通性に注目してグルーピングしたものをファミリと定義する方法は、Weiss 氏らが考案したFAST(Family Abstraction Specification Technique) という手法に基づいています。

DSL は小さなドメインを対象にしていて、ドメインが変化しない限りはうまくいったそうですが、ドメインは変化していくものです。DSL は、デバッガなど周辺技術との密な関係性の中で成立するため、その変化に対しては脆いという問題がありました。

ただし、共通性／可変性分析自体は非常に有用で、ドメイン分析に対しては非常に多くの収穫があったそうです。

分析の結果得られる共通性／可変性テーブルの内容の埋め込み（注: 解決ドメインの抽象による実装）に関して、

• DSL で埋め込むと、固くなりすぎ、脆くなる。
• C で埋め込むと、言語特有の制約が多く、開発者の intentionality（意図）がわからなくなる。

という課題がありましたが、C++ を用いることで、よりうまくいくようになりました。

オブジェクト指向（1995）

Coplien さんは、C++ を

共通性／可変性分析のための、汎用言語キットである

と捉えます。

その視点で見たオブジェクト指向は、次の4項目の構成要素で理解されるようになりました。

1. Common Signature
2. Common Data
3. Variation in Data
4. Variation in Algorithm

また、polymorphism / instantiation は、共通性／可変性のバインディングタイム（注: 共通性／可変性が変数に束縛されるタイミング）の選択の問題として捉え直されることになりました。

オブジェクト指向（DCI 時代）

Coplien さんによれば、更にこの後、3段階の気付きを経て、現在のオブジェクト指向理解へとつながっているそうです。

1段階目: There  is no OO in C++

• 2010年くらいまでは、オブジェクト指向という言葉を、抽象データ型（ Abstract Data Type: ADT ）という意味で使っていた。
• C++ は実際には抽象データ型ではなく、具象データ型（ Concrete Data Type: CDT ）であるということ。

2段階目: There are no objects in source code

• C++ プログラムはソースコードである。
• そこにはオブジェクトは存在しない。ソースコードに記述しているのはクラスである。
• 多くの人々が Java などの言語でやっているのはクラス指向プログラミングである。

3段階目: OO is mental model

• Trygve Reenskaug 氏とオブジェクトとは何か、オブジェクトパラダイムとは何かについて話し合い、DCI が生まれた。
• DCI は、抽象データ型の実装を意味したこれまでのオブジェクト指向とは別の視点を与える。
• 実行時におけるオブジェクトのネットワークがどのように問題を解決するかに注目する（ Alan Kay の定義）。
• 我々はクラスとロールをごちゃまぜにして考えていた。
  • 抽象データ型について考えるのがクラス指向。
  • ロールについて考えるのがオブジェクト指向。
  • 抽象データ型＋インスタンス化がロールを実行（play）。

MPD と DCI

MPD は、クラス指向のレイヤーにおいてドメイン分析を行う時、ソフトウェアファミリの共通性／可変性分析を通じてドメインモデルを構築する手法を提供します。

DCI は、我々のメンタルモデルに基づいて、オブジェクトどうしの相互作用を定義します。そこでは、抽象データ型としてのクラスに具体的なロールを注入されたオブジェクトが、特定のコンテキストのもとに配置され、相互作用するという、動的な側面を捉える方法を提供します。

以上を簡単にまとめると、次の表のようになるかと思います。

歴史的には MPD が先行しました。それは後に、モデルの静的な構造の分析を行うための領域を担う設計方法論という捉え直しがされました。そして、オブジェクト指向に対する新しい視点を提供する DCI が、クラス指向では扱うことが難しかった、モデルの動的な関係性を捉えるための方法論として提起されています。

Time and Space と DCI における共通性／可変性

DCI は、オブジェクトどうしの相互作用に注目します。つまり基本的には時間の経過（シーケンス）が意識されます。しかし、あるロールを付与された複数のオブジェクトが配置されてこそ、相互作用が成立するものです。

コンテキストとは、このように、ある状況に参加する主体の空間的配置と時間的な相互作用の総体として捉えられるものと言えます。

ここで、日本人にとってはありふれた「間」という概念が取り上げられました。具体例としては次のようなものが話題にあがりました。

• 歌舞伎（ Coplien さん）
• 龍安寺の石庭（ @koriym さん）

また、アレグザンダーの考案したパターンランゲージに話が及びました。パターンランゲージは、建築の構造（空間的なパターン）だけではなく、その構造が生み出す人々の相互作用（時間的なパターン）も内包したものとして理解されるべきです。

pattern of behavior = pattern in space + pattern in time

セッションの終盤では、このように、DCI が担う領域における共通性／可変性概念の適用可能性が示唆されました。

さいごに

会場を提供していただきましたヴァル研究所様、DCI Tokyo スタッフの皆様、今回もすばらしいイベントとなりました。ありがとうございました。

次回は、ワークショップ形式での開催も視野に入れながら、DCI Tokyo 3 が開催されることと思います。MPD / DCI / Lean Architecture に興味のある方は、ぜひご参加ください。