ドメイン層にメタデータは入れないでね

某社内フレームワークがOSS化されたという記事が出て、ツイッターでいろいろつっこまれていたが、低スキル志向な組織では結構普遍性がある話なので、ちょっとメモしておこう。

どういうものかというと、「DDDを意識した」と謳ってる Scala フレームワークで、全てのエンティティの基底となる trait として EntityModel なるものが定義されていて、以下の属性を持つという。

• エンティティのIDを表す id
• データ更新日を表す updatedAt
• データ作成日を表す createdAt

まあ、ID をエンティティに含めるかどうかについては、最近の関数型DDD界隈では議論があるけど、一応ここでは良しとしておこう。でも、データ更新日とデータ作成日はないわな。メタデータやんけ。

注文日時とか支払い日時とかならわかるけど、データ生成日って・・・どうしてこうなった？

百歩ゆずって、「データ○○日」がユビキタス言語になるような、ある種のドメインのある種のエンティティがあったとしても、そんなのむしろ特殊ケースだわな。全ての DDD エンティティの共通属性なんかにはならない。まして OSSとか・・・

要するにこれ、永続化層の都合で考えてるんじゃないのかね。ドメイン駆動とは正反対に。

なんか関連記事では「DDDを意識した」とか言ってるけど、むしろ逆にドメインモデリングなんか全然意識したこともなく、まして Persistence Ignorance とか聞いたこともない感じの技術者が、エンティティを「DBテーブルの受け皿」くらいにしか認識できてないまま、社内標準共通カラムとかをケースクラスに反映させちゃうときにやらかす、ありがちパターンなんだが。

こういう、下手くそなフレームワークを作って組織内に展開すると、ずっとこれ使うことが強制される部下たちが可哀そうなんだよな。

「プロダクトの標準化」とか言っても低レベル側に倒してるだけだから、これだとスキルが高い側に淘汰圧がかかって、低スキルメンバーしか残らなくなる。出来るメンバーからアホらしくて抜けていくから、組織的にも良くないだろうし。

もしオフショアやら若手やらでスキルムラが酷すぎて、標準化目的のフレームワークで型にはまった金太郎飴を作らせざるを得ないってあれなら、まず安易な人材調達から改善しないとダメだろうな。高スキルメンバーだけで数十〜数百人集めてる組織だってあるわけだし。

三行要約

• メタデータをドメイン層に入れるのは止めましょう
• DDD って言いたいだけで DDD って言うのは止めましょう
• ポンコツフレームワークを社内展開するのは止めましょう

補足

• メタデータがドメインモデルに含まれないのは当然として、関数型DDD界隈では、エンティティは自分の ID を持つべきではないという流派もある。（参考)
• ツイッターで突っ込まれていたのは ID の型の指定の仕方だったが、ドメイン層にメタデータを混入させてしまっている事の方が余程ひどい問題。
• フレームワークを標準化目的---プログラマを型にはめるために作ったり使ったりするのって、本当に酷い愚行で、組織学習の強烈な阻害要因だと思うけど、別の機会に書きたい。