#accounting.system

[iteman]

DDD読書会@大阪(最終回)のLT資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka

DDD読書会@大阪(最終回)のLT資料「ドメイン駆動設計で気づいたこと～権利の概念とERP分析への適用」 #dddosaka from akipii Oga

[iteman]

データ中心アプローチでいう「データモデル」は、正確には「モデル（模型）」ではなくて、帳簿組織の仕様そのもの。DDDでいうドメインモデルは本当はドメイン層のAPI仕様。後者が前者の上に成立する関係になる。両方とも、何かの「模型」ではなく「仕様」。モデルと呼ぶのは不正確と思うな。

Twitter / sugimoto_kei

[phpmentors]

Practical DDD #3: モデルの深さ

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

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

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

[iteman]

システム作りにおいて、ソフトウェア構造の設計が醍醐味のひとつであるとすれば、管理過程とそのツールである帳簿構造（記録構造）の設計は、もうひとつの醍醐味。両方とも面白いことこの上無い。どちらが仕事として上等なんて話は馬鹿らしいくらい。

Twitter / sugimoto_kei

[iteman]

だから、事業過程（ビジネス自体）と管理過程（そのための、記録・情報管理）を区別するのが大切と思うんですね。オブジェクト指向分析ではその線引きにあまり拘らず「現実世界」と呼ぶので、管理過程を与件と見なしてしまうワナに落ち入り易いのではないかと危惧するのです。

Twitter / sugimoto_kei

[iteman]

設計者にとって、事業過程は与件であり、管理過程はエンジニアリングの対象である。

 杉本啓

[iteman]

深いモデルにするには、クラスは単なる名詞ではなく、業務ロジックやビジネス上のお金のやり取りも反映したものにすべき。 そのためには、やはり何らかの視点が必要。 その視点の一つが「責務のレイヤ」パターンであり、Policy-Control-Operationという考え方であり、T字型ERで言う事業過程・管理過程・組織過程の分類でもある。 そして、貨物輸送システムがビジネスで役立つシステムになるには、最終的には、お金のやり取りを具現化する「船荷証券」という権利をやり取りすることになる。 そこまで行き着いて、初めて、深いモデルになる。 深いモデルは、現れるクラスの凝集度が高い。 深いモデルになって初めて、モデルはユビキタス言語になる。

ユビキタス言語は概念群の凝集である: プログラマの思索

[iteman]

データモデリングには、帳簿組織のあり方を考えるための知見が盛り込まれている。射程範囲は狭いが、その領域を効果的に扱うための道具立てが揃っている。つまり、データモデリングの枠組みは「DSL(Domain Specific Language,ドメイン固有言語)」のひとつである。

オブジェクトモデリングとデータモデリング: 設計者の発言