このエントリーは「ドメイン駆動設計 \#2 Advent Calendar 2018」の20日目です。（1日遅れですが、空いていたので登録させていただきました。）

はじめに

ドメイン駆動設計（Domain-Driven Design）にはドメインを反映したモデルを作り上げるためのいくつかの要素があり、それらは戦略的設計と戦術的設計に分類できます。（戦略的設計をマインド、戦術的設計をパターンと呼ぶ人もいます。）

戦略と戦術、どちらも等しく大事です。（戦術だけ実践したものを「軽量DDD」と言いますが、得られる効果は薄くなります。）

実践的モデラー（Hands-on Modelers）は、戦略と戦術の両方向からモデリングを行います。

モデルとは

モデラーの前にモデルについて、改めて理解しておきます。

モデルとは、抽象と捨象を経て「何かしらの側面を強調したもの」です。
エリック・エヴァンスのドメイン駆動設計の中では、「地図」の例が載っています。
18世紀の中国の世界地図は、中央に中国が配置されて大半を占めているというものです。国内に意識が向いていた当時の中国社会にふさわしいものでしたが、中国以外には役に立たず、もちろん、現代の中国にも全く無意味だと説明されています。
現在でも使われている地図の例だと、メルカトル図法の地図などがあります。メルカトル図法の大きな特徴は角度が正しいので、方位磁針を見ながら常にその角度へ進むようにすれば、目的地に到着できるという特徴があります。一方で、緯度によって縮尺が異なり、距離や面積比は正しくありません。距離や面積比を正しく知りたい場合には、別のモデルである地球儀などを用いることになるでしょう。

モデルは現実に対する1つの解釈と言われていますが、一方で、「現実世界を正しく表現したもの」ではないということも覚えておかないといけません。

モデラーとは

モデラーとは、モデルを組み立てる（モデリングする）人々です。

製造業では「高度なスキルを持つ技術者が設計し、それほどスキルのない労働者が製品を組み立てる」という構図があります。製造業はソフトウェア開発のメタファー（比喩）として使われますが、これをそのままソフトウェア開発に持ち込むと破綻します。ソフトウェア開発はすべてが設計だと言われています。

エリック・エヴァンスのドメイン駆動設計の中では、以下のような文章が書かれています。

コードを作成する人々がモデルに責任を感じていない場合や、アプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になってしまう。

一方、モデラーが実装プロセスから切り離されている場合、実装に伴う制約に対する感覚を、モデラーは習得することがないか、できてもすぐに失ってしまう。

前者は「複雑なドメインの設計は、モデルに基づかなければならない」というドメイン駆動設計の前提の話になります。また、先述した製造業のメタファーを持ち込んで破綻する原因でもあります。

後者が「実践的モデラー」としての重要な行為です。実用的なモデルを組み立てるには、コーディングに伴う微妙な事情を含めてモデリングします。先述した「モデルは『現実世界を正しく表現したもの』ではない」というのは、このような作業の結果からになります。

モデルに貢献する技術的な人は誰でも、一定の時間をコードに触れることに費やさなければならず、モデリングとプログラミングを厳密に分離するとうまくいきません。（好むと好まざるとに関わらず、プログラマはモデラーでもあると言われています。）
これはモデル探求のうずまき（Model Exploration Whirlpool）として表現されています。「シナリオ（Scenario）」と「モデル（Model）」、そして「コードによる探査（Code Probe）」でループを回します。（日本語訳されてる方もおりますので、ご紹介させていただきます。）

例1: やかんのモデル

やかんの責務には「水を沸騰させる」「水を注ぐ」などの他に「水の沸騰を知らせる」というものがあります。
アプリケーションのためにモデルを機能させる方法を理解していない場合、「そもそも沸騰を知らせる機能が付いていない」「【温度センサー】など過剰な実装がされる（注ぎ口を笛にするだけで十分なのに）」といったモデルになってしまう恐れがあります。

例2: 年齢のモデル

人間は年齢を持っていて1年ごとに歳を取ります。この現実を愚直に実装すると「誕生日になったら、対象者の年齢を1つカウントアップ（+1）する」というようになります。（例: データベースに年齢（age）を持って、誕生日になったら「25」から「26」とする。）
これは「実装に伴う制約に対する感覚を、モデラーが習得していない」例で、（一般的に）良くない実装だと考えられます。以下のような懸念がある為です。

・毎日0時になったらデータ更新する？夜間バッチ処理で書き換える？
・全データ閲覧する必要がある？その日が誕生日のユーザーだけ抽出する？
・0時時点で反映されてなくても大丈夫？タイムラグは許容する？
・バッチがエラーになったら？そこまでする必要がある？

年齢の実装は、データベースには誕生日（birthday）を持って当日日付から動的に算出するのが良いとされています。（少なくとも、前述の懸念は回避できます。）
これは現実とは（多少）異なりますが、実装の制約が加味された実践的なモデルであると考えられます。

さいごに

DDDが戦略と戦術、どちらか一方のみで語られる場面を見て、「ドメイン理解も実装プロセスも、両方とも大事！両方を組み合わせてこそ、良いモデルになるよ！ちゃんと本にも書いてあるよ！」ということを伝えたく、書かせていただきました。

抽象的な話で恐縮ですが、以上です。