ドメイン軽視のメンタルモデル

自分はわりとシステム開発の対象とする問題領域、つまりドメインをどうモデリングするかについて関心がある方なので、ツイッターのTLなんかでも、ドメインのモデリング／コーディングについて熱心に語っているツイートが自然と多くなる。なので例えば DDD を応用して日々研鑽している人が多いなあという感想をもってしまいそうになる。

ところが、世間一般ではかならずしもそうではない。

一応それなりに高スキルなメンバーを集めたチームですら、ドメインを扱う技能は意外と重視されない。そもそも高スキルチームを目指してのメンバー集めの段階で、インフラ〜ミドルウェアにかけての最新プロダクトやライブラリの経験が評価されることはあっても、ドメインのモデリングについて触れられることはまず無い。

技術者評価の面でも、ドメイン以外に関するスキルだけが注目される。大規模で複雑なドメインの中に適切に境界を定めて粒度と整合性のトレードオフを解決したとか、関心事の分離を徹底してドメインのコードをより純化したとか、そういったことは話題にもあがらない。ドメインモデリングに関する功績や努力はほぼ常に無視される。

ましてや低スキルチームでは、そのチーム内では若干マシなプログラマが「共通コード」やら「フレームワーク周り」やらを担当する一方で、コードベース全体のその他 90〜95%くらいを占めるビジネスロジックを、人材市場でかき集めた十把一絡げの人材と、経験１・２年の初心者で構成された、何にも知らない人海戦術軍団で対処することになる。

そうした現場では、ドメインモデルなど最初から最後まで一瞬も考慮されることなく、DBアクセスとHTTP入出力のあいだに、うず高く積まれた手続き型コピペコードからなる糞コードの大山脈が形成されるが、低スキルチームでは管理職以下だれもがそれで当たり前だと思ってる。ビジネスロジックのコーディングとはそういうものだと、上から下まで普通に認識されている。

ちなみに DDD の Eric Evansはこう言っている。

Apply top talent to the CORE DOMAIN, and recruit accordingly.

これが真逆だから、チームのスキルバランスもおかしくなる。成果物となるプログラムの大部分はドメイン固有のコードなわけで、時間もマンパワーも大部分そこに費やされるのだから、ドメイン層にこそ知識や技術や経験や才能を集めて洗練させるのが本来優先になる。「フレームワーク周り」の層なんか、ドメインを洗練する初期の過程で必要性が高いものから自然に形成されれば良い。

またビジネスロジックに永続化層の都合を混在させて Persistence Ignorance を壊したり、ひどい場合は「大規模なドメインでのトランザクションスクリプト」に至ってしまうのも、ドメインの軽視が主因。ビジネスアプリケーションのドメインとはそもそも複雑なものだという認識が足りないからそうなる。

さらに、ドメインモデルは一発で正解を出すものではなく継続的に洞察を深めながら進化させるものだという認識も、ふつうは全く足りないからテストもお気楽に省略される。MVPを厳選してなんとかファーストリリースにこぎつけたとしても、その後早い段階で詰んでしまう。

ちなみにそういう風景って、なんとなく受託 SIer あるある的なイメージだけど、今では自社Webサービス業界でもすごく多い。推測だけど、受託SIer の土建的世界観で育った中堅「SE」が、そのままのメンタルモデルを強固に維持したまま、いわゆる「自社サービス」の「Web業界」に流れてきて同じことをやってるのではないかと思う。

こうしたドメイン軽視のメンタルモデルには共通の起源があるように思うが、別の機会に書きたい。