DDD Allianceの「第3回 実践的ドメイン駆動設計ワークショップ（2日目）」に参加しました。
先週に引き続き、DDDのワークショップに参加しました。
いきなりですが、ワークショップ終了後の感想戦から。
前回の終わりに「あるサービスの料金プランについて概念モデルを作る」という宿題が出ていました。 私はその宿題に取り組む過程で、公開されている料金データを元に独自の解釈と世界観を作り上げてしまう、という危険な罠にハマりました。
考えてきた内容を増田さんに聞いてみたところ、失敗する人工知能のシステムに似ている、と言われてハッとしました。 最近読んで影響を受けた本が、人工知能の文脈から書かれた本だったからです。
- 作者: 來村徳信,人工知能学会
- 出版社/メーカー: オーム社
- 発売日: 2012/04/20
- メディア: 単行本（ソフトカバー）
- クリック: 1回
- この商品を含むブログ (1件) を見る
（この本がDDDと相容れない、と言いたいのではありません。オントロジーという概念はDDDの文脈、特に「知識のかみ砕き」において強力なツールになる予感がしています。）
DDDは「人が対象をどのように認識し、意識するか（＝概念モデル）」を大切にします。 しかし、私が料金データを分析して気づいたことは「現在の金額設定において存在しているように見える、値引もしくは値上金額と適用条件の組」であって、概念モデルではありませんでした。
データから特徴的な傾向を見出すこと自体は、「隠された関係性を探す」1つのヒントになると感じています。 このヒントをDDDの文脈に活かすためには、「データの特徴的な傾向が、どのような概念モデルの表れであれば違和感が無く、かつ分かりやすいか？」という追加の問いかけが必要でした。 パターン化や簡略化は結果論であって目的ではないということを肝に銘じました……。
ワークショップの話。ここまで書いて力尽きたので列挙で。
- 詳細が分かっていない概念が存在するなら、コードとしてもざっくりした定義で型を作る。定義の状態がドメイン把握の状態を反映しているのは健全。
new 素泊まり料金() - 特徴を文章として書き下せないうちは、設計もぎこちないものになる。
- 最初の概念クラスは文章を書き下したものにする。実際のシステムとしては過不足があって当たり前なので、まずは そのまま 書き下す。
- 分かりやすい設計はテストをあまり必要としないし、結合テストに至っては不要で、それが必要になるのは背景に設計上の無理がある。
- 概念クラスがツリー構造として表れたら、上部や下部と密結合の臭いがするので要注意。
- 概念クラスがネットワーク構造として表れるのは、DDDとしてはきれいな兆候。
2日間の総括。
「相手の言葉に耳を傾け、聞き出し、書き表し、声に出して読み、整理する」という、国語力を非常に求められるワークショップでした。 「制約によるコミュニケーションの不足」は普遍的な課題だと思っていますが、地道な国語力向上こそ克服の鍵になりそうだ、という感触を得ました。
