第４回ドメイン駆動設計読書会の感想

第４回ドメイン駆動設計読書会@大阪に参加してきた。
感想をラフなメモ書き。

【限定募集：第1回の申込者のみ、参加登録可能】第４回ドメイン駆動設計読書会@大阪 - ドメイン駆動設計読書会@大阪 | Doorkeeper

第４回ドメイン駆動設計読書会@大阪 from akipii Oga

Pages ・ dddosaka/reading_ddd_report Wiki

【0】「ドメイン駆動設計」の第1章の最初の例1と2を輪読して、みんなで議論してきた。
改めて、自分の理解が浅いことを痛感してきた。
食いつまんで理解しているだけなので、文章を一つずつチェックして議論してみると、新たな気付きや理解が生まれる。

【1】例1.1では、ビジネスルールをポリシークラスとして抽出することで、隠された概念を見える化させる。
当初の浅いモデルから「深いモデル」へ進化していく。

P.21では、貨物の輸送システムをドメインエキスパートとモデリングしていくと、モノを運ぶのではなく、船荷証券という法律ないし会計の概念が現れたという話がある。
これがまさに、浅い業務のモデルから、ビジネスの本質をとらえた帳簿モデル(渡辺さん、佐野さんが主張するモデル)になるのだろう。

興味深かった議論は、業務知識を知らない開発者が作った浅いモデルから、どうやって、業務の本質をとらえた深いモデルへ変換することができるのか？ということ。
結論としては、やはりそう簡単にはブレイクスルーが起きて深いモデルへ進化することはなく、業務知識を知っておかないと、そんなモデルは出てこないだろう、という話に落ち着いた。

【2】例1.2のユビキタス言語では、貨物輸送プログラムにおいて、「経路仕様を満たす輸送日程を見つける」モデルは、「経路仕様」クラスを使うことがキーポイント。

このモデルは、「責務のレイヤー」パターンを使えば、意思決定支援層が経路選択サービス、業務層が経路仕様、貨物、輸送日程になり、能力層が行程クラスに相当する。

興味深い議論としては、経路仕様クラスのようなポリシークラスはどうやって導き出せるのか？という話があった。
普通の設計工程では、このようなビジネスルールだけを集めた仕様書はないから、ポリシークラスの発想は出てこないかもしれない。

僕の経験では、会計システムにおける計算仕様書という特別な設計書を作成した経験があるので、それがポリシークラスに相当するだろうと思っている。
計算仕様書の中身は、消費税や販売価格の計算方法(税込金額からの税はがし処理、税計算の丸め込み・切り上げ・切り捨てなど)をまとめたもので、ユーザにとってかなり重要な仕様だ。
この仕様の正当性を最終的には、会計の専門家(税理士、公認会計士)に認めてもらう時もある。

【3】ユビキタス言語とは、ドメインエキスパートと開発者が互いに理解しえあえるドメイン知識。
ユビキタス言語があれば、どのチームでも、どの作業でも、共通に使える概念としてモデルからソースに落とし込める。

ユビキタス言語がない場合、業務の専門家と開発者はお互いに通訳しながら会話しなければならない。
また、開発者同士でも、お互いに通訳して、相手の概念を理解する時もある。
通訳はコミュニケーションのロスを発生させて、コミュニケーションを鈍らせる。
これは方言ともいえる。

ユビキタス言語は、業務の用語集に似ている。
用語集がない場合、ホモニム(同音異義語)やシノニム(異名同義語)が発生してしまい、チームが混乱してしまう。
チームごとに方言があるような状態が相当するだろう。

ユビキタス言語には使用範囲がある。
それが「境界づけられたコンテキスト」になる。
そして、複数チーム、大規模システムにおけるサブシステムの単位でユビキタス言語として使われる概念が違う場合(つまり、方言)、「コンテキストマップ」によって、方言を対応付ける。

境界づけられたコンテキストを意識しなければ、ユビキタス言語はあいまいに使われてしまう。
コンテキストマップがなければ、方言の対応を開発者自身が行わなければならないので、意思疎通がしにくくなる。

また、大規模システムになれば、ユビキタス言語をレイヤーで分ける。
「責務のレイヤー」がまさにそうで、意思決定支援・業務・能力の3つの層で分けて分類する。
「責務のレイヤー」に似た話としてREAモデルを久保さんから教わった。
REAモデルは、リソース（Resource)、イベント（Event）、エージェント（Agent）の3つでビジネスモデルを構築・分析するやり方。

要求開発アライアンスのビジネス・モデリング道場 - REAとビジネスパターン入門(1)：ITpro

テーブル設計 | システム設計日記

REAモデルから考えても面白かもしれない。

【4】他に興味深い感想は、ユビキタス言語はどんなものなのだろうか？という議論。
僕も含めて、ほとんどの参加者はドメイン駆動設計をしたことがないので、ユビキタス言語は用語集みたいなもの？　ユビキタス言語はAPIみたいなもの？みたいなアナロジーで議論していた。

ユーザと開発者が同じ概念で会話しあうという場面を想像できなかったのだ。
久保さんが何度も説明してくれたが、やはり自分でモデルを作ってみないと分からないと思う。

【5】個人的に不明に思うのは、ドメイン駆動設計の成果物は何なのか？
やはり、UMLのクラス図が多いのか？

普通の要件定義では、AsIsの業務フローを洗い出し、それに対して、人や組織をマッピングし、あるべき業務フローへ洗練させる。

このやり方は王道であるが、大量のドキュメントを作る羽目に陥りがち。
また、AsIsモデルを作るだけで精一杯なので、あるべきモデルを提案する頃には時間切れになる。
すると、現状の問題を残したままシステム化してしまい、システム稼働後に、ユーザから、こんなはずではなかったという苦情を受けてしまいがち。

おそらく従来のPOAに近い手法ではなく、ドメインモデル主体なのだろうと推測する。
勉強会でさらに議論してみる。

【追記】他の方の感想をリンクしておく。

ドメイン駆動設計読書会、第4回のメモ - nyanp::blog