「DDDにまつわる諸課題の整理」への自己レス

たなかこういち @Tanaka9230

そもそもさ、'00年代のエンタープライズ業界で「ドメインだー」「コモナリティ・バリアビリティの分析だー」「関心の分離だー」って言われ始めたのは何でだったかを、この記事書いてて思い出したよ。そのころから業務プロセスの変更が頻発しはじめたからだったのだ。

たなかこういち @Tanaka9230

記事中では「コンテキストの交錯はあまりなかった」と書いたが、ニュアンスは逆だな。そのころから「コンテキストの交錯が頻発し始めた」んだった。相対的には今のWeb系／スタートアップ系とは比較にならないほど静かだったことに変わりはないが。

たなかこういち @Tanaka9230

当時的な対策案は、次々現れる個別要求にシステム全体として逐次追従していては間に合わないので、比較的変更ライフサイクルの短いユースケースから、比較的変更ライフサイクルの長い永続化データとその周囲を分離しよう、というものだった。 atmarkit.co.jp/fdotnet/softfa…

たなかこういち @Tanaka9230

その手の分離は、ドメイン工学ではCommonalities/Variabilitiesといっており、 DDDのアプリ層－ドメイン層、DCIのインタラクション－データ、萩原氏記事でのユースケース－ドメインオブジェクト、は、その観点からみて全て同じ目的のものだといえる。 en.wikipedia.org/wiki/Domain_en…

たなかこういち @Tanaka9230

萩原氏記事では、ユースケースを「要求モデル」、ドメインを「資産モデル」と言っている。@jcoplien 氏は、前者を"what-the-system-does"、後者を"what-the-system-is"と言っている。（※commonalitiesは後者、variablititiesは前者に対応します。）

たなかこういち @Tanaka9230

以上の考えは、既にデータ資産や業務ルールを抱えていたエンタープライズシステムにとっては、確かに適切だったと思う。 今でももちろん、一式のデータ資産を抱えてて、かつ、様々な業務プロセス要求に次々と答えなければならない環境にあるなら、同様に有効でしょう。

たなかこういち @Tanaka9230

では、今時のWeb系スタートアップで、システムに対するプレッシャーはどのようにあるか？「既にデータ資産があって、かつ古い業務があって、そこに新しい業務への対応が必要となった」という文脈にあるかというと、たぶん無い。「データ資産は蓄積中で、一つ目の業務に対応中」だろう。

たなかこういち @Tanaka9230

つまり、CommonalitiesとVariabilitiesを分離すべきだ、とかいい始める以前の段階にあると思われる。Commonalitiesとして独立させるべきドメイン（←狭義の）なんてのがまだ確固たるものとしては存在してないのだ。

たなかこういち @Tanaka9230

アドベントカレンダーの記事中では、「コンテキスト」を概ね要求のスコープとして理解し、そいう要求＝コンテキストに振り回されないような"ドメイン"を作るべき、と書いた。この考えは、既にデータ資産と既存業務を抱えているということを暗黙的に大前提としていた、、ということ気づいた。

たなかこういち @Tanaka9230

スタートアップの置かれている環境では様相が異なる。スタートアップの文脈では、"コンテキスト"は（※やべ、語彙が交錯している）要求の細分化と要求の相互不可侵を意味し、"ドメイン"は各コンテキスト下の細分化された業務（機能とデータ）そのもの、として解釈されている。こいつはMSAのことだ。

たなかこういち @Tanaka9230

スタートアップでの課題は、既存に対する変更要求への柔軟さではなく、膨大な新規要求へのパラレル対応、なのだった。

たなかこういち @Tanaka9230

スタートアップも成長して"二巡目"に入れば、既存への変更要求への柔軟さという課題が湧き上がるのは必定。 ・・・結局は、「変更要求への柔軟さ」目線と「新規要求へのパラレル対応」目線とは、まー結局はその時その時にバランスとるしかないよね。