新しいプロジェクトを始めるとき、いつも同じ誘惑がやってきます。フレームワークのドキュメントを開き、データベースを用意し、エンドポイントをつなぎ、とにかく動かしたくなる。その衝動をもう一時間だけこらえて、地味な作業を先にやります。ドメインをモデリングするのです。
ドメインモデルとは、つまりシステムが実際に扱う名詞と、それらを結ぶルールのことです。注文、入札、決済。どんな状態を取りうるのか、何がその状態を変えるのか、常に成り立っていなければならないことは何か。そこに Postgres も React も、どのクラウドに載せるかも入る余地はありません。問題そのものについての話です。
ここから始めるのは、モデルこそ間違えると最も高くつく部分だからです。フレームワークは差し替えればいいし、データベースは移行すればいい。けれど中心となる抽象がビジネスの実際の考え方とずれていると、その後のすべての機能が木目に逆らって進みます。コードは特殊ケースであふれ、それは実のところモデルが漏れているサインです。
役に立つ習慣をいくつか挙げます。
- 現場の人が呼ぶとおりの名前で呼ぶ。倉庫チームが「委託(consignment)」と言うなら、コードも
consignmentと書きます。shipmentGroupV2ではなく。 - ありえない状態は表現できないようにする。注文が下書きと支払い済みを同時に取れないなら、型がそれを許さないようにします。そのルールは自分で覚える代わりに、コンパイラに持たせておくのです。
- モデルは外の世界を知らないままにする。HTTP も SQL も JSON も知る必要はありません。それらはモデルを包む殻であって、その逆ではありません。
これは形式ばった儀式でも、図のための図でもありません。私の「モデリング」はたいていテキストファイル一つと TypeScript の型がいくつか、午後のあいだに三回ほど捨てて書き直します。大事なのは、解の形を決める前に、問題の形で考えることです。
最近おもしろいのは、AI エージェントが後半、つまり足場づくりや配線、ボイラープレートといった作業を実に上手くこなすことです。だからこそ前半の重要性は下がるどころか、むしろ上がります。渡すモデルが明確なほど、返ってくるコードも良くなる。あいまいなモデルを渡せば、自信満々の的外れが返ってきます。
だからドメインが先。あとはすべて配管です。