Practical DDD #3: モデルの深さ
ドメイン駆動設計の「モデルの深さ」などについての考察、前回の続きです。
前回の記事では、エリック・エヴァンスのドメイン駆動設計で書かれているモデルの深さというのは分かりづらいので、別の尺度としてモデルに表れる概念群の凝集度を考えてみてはどうか、ということに触れました。また、ユビキタス言語にあらわれる概念と概念が互いに関連しあい、述語でつながっていれば、パターンランゲージのようにドメインの知識を豊かに伝えることができるでしょう。
今回はドメイン駆動設計第1章の最後のストーリーで到達した「船荷証券（ふなにしょうけん）」というものから、モデルの深さについて考えてみます。
そもそも海運ドメインについて
私には海運ドメインについての知識がありません。エヴァンス氏自身がそうだったのかはさておき、ドメイン駆動設計のストーリーとしても、プロジェクトの初期において開発者には海運ドメインについての深い知識はないという想定になっています。しかし、ドメインモデリングを行うには対象ドメインの知識が必要です。エリック・エヴァンスのドメイン駆動設計では、ドメイン知識を得る方法としてドメインエキスパートとのコミュニケーションが中心的に取り上げられていますが、対象ドメインについての知識を得る方法は他にもたくさんあります。『ドメイン分析・モデリング―これからのソフトウェア開発・再利用基幹技術
- 目的業務
- 業務マニュアル
- そのドメインの教科書、パンフレット、用語集
- ドメインエキスパートへのインタビュー
- ビジネスの現状
- ドメインの境界、スコープ、近隣ドメイン
- 使用可能なテクノロジ
- D-AMEの適用範囲
- 開発事例
- 既存のシステム（パッケージ）
- 既存のシステムの開発担当者へのインタビュー
- 既存の仕様書、マニュアル
- 実現プラットフォーム
- ひな形アーキテクチャ
- 法規
- コスト制約
(D-AMEというのは、「ドメイン分析・モデリング」で紹介されているドメイン中心の分析・設計・開発スタイルの名称です。Domain Analysis, Modeling and Engineeringの頭字語)
ドメインエキスパートへ素朴にヒアリングするわけではなく、事前に様々な知識を揃えておけということで、これは当たり前のことですね。このリストを見ると、自社サービスやいわゆる業務システム以外のシステムを開発する場合も例外ではなく、ドメイン知識を得るための材料はたくさんあるということが分かります。最近ではWebで検索することでかなり手軽に仕入れられる情報も増えていますね。
JETRO（日本貿易振興機構）のページのFAQで「船荷証券」について調べると49件もありました。
また、実際に海運関係のお仕事をされていた方のホームページも見つかり、次の図のように端的に海運業を表すモデルも示されていました。
- 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)を含む貿易取引の仕組み自体は「深い」ですよ。歴史の中で洗練されてきたモデルだし。でも、取引で用いるそうした記録のモデルと、貨物や船舶といった「現実のモノ」を対象にしたモデルの違いは、「深さ」とは別の軸上にあるのですね。
本文で「船荷証券は深い概念ではない」と書きましたが、これは「対象をモデリングした結果として表れるもの」という括りで見れば、ということです。杉本さんの仰るとおり、この海運ドメインは歴史があり、それ自体が深く洗練されているのですね。しかしそのことと、開発するシステムにおいて「深く蒸留されたモデル」を作り出すこととは、別の軸の話であるということです。