「このプロジェクトはDDD（ドメイン駆動設計）を採用しているので、エンティティと値オブジェクトを厳密に分離し、ユビキタス言語でドメインモデルを構築します」
気取ったアーキテクトや、技術書を斜め読みしただけの若手がドヤ顔でこう語り始めた瞬間、そのプロジェクトの破滅へのカウントダウンが始まる。
DDDそのものは、複雑なビジネスロジックをソフトウェアに落とし込むための立派な思考体系だ。だが、現場で実際に起きているのは何か。
用語のカッコよさに酔いしれた連中が、実業務そっちのけで「オレが考えた最強のクラス設計」に没頭し、文字列1行を画面に出すためだけに何重ものラッパーオブジェクトを生成する。結果、開発スピードは牛歩のように遅くなり、無駄なメモリ消費でサーバは悲鳴を上げ、納期直前に全員で青ざめる。
新しい横文字をありがたがり、コードを複雑怪奇にして「設計した気」になっているアホどもを見るたび、吐き気すら覚える。
30年以上前の焼き直し：新しい技術と勘違いして拝む信者たち
そもそも、DDD信者たちに問いたい。お前たちは本当に「ドメイン駆動」を新しい最先端の思想だと信じ込んでいるのか？
現実を教えてやる。業務（ドメイン）の事象や状態変化を捉えてコードを駆動させる考え方など、通信デバイスや組み込みファームウェアの世界では30年以上前から「イベント駆動」として当たり前にやっていたことだ。
限られたメモリ、細い通信帯域、リアルタイムの信号処理。ハードウェアの限界と戦ってきた先人たちは、「何が起きたら（イベント）、どの状態をどう遷移させるか」を極限までシンプルに、研ぎ澄まされたロジックで実装してきた。
それを今さら、Web系やエンタープライズの連中が「エヴァンスの本に書いてあった！」「オニオンアーキテクチャ最高！」と、新しい用語で化粧し直されただけの車輪の再発明を神棚に祀り上げて拝んでいる。
歴史も知らず、本質も理解せず、ただ海外から輸入されたバズワードに踊らされている姿は、滑稽としか言いようがない。
値オブジェクトの乱用：業務が1ミリも進まないクラス生成の地獄
DDDをこじらせた現場に入ると、必ずと言っていいほど「値オブジェクト（Value Object）教」の狂信者に遭遇する。
彼らのリポジトリを開くと、背筋が凍るようなコードが広がっている。
UserIdクラスUserNameクラスUserAgeクラスZipCodeクラスAddressStringクラス
ただの「ユーザーID（数値）」や「氏名（文字列）」を表現するためだけに、狂ったように個別クラスを乱造する。
「プリミティブな型（intやstring）を生で使うのは悪だ！ 不正な値を防ぐためにすべて値オブジェクトにカプセル化すべきだ！」
彼らは教科書通りの正論を叫ぶ。だが、その結果として現場で何が起きるか。
ユーザー情報を取得して画面に表示するだけの機能を作ろうとする。すると、コントローラーからユースケース、ドメインサービス、リポジトリを経由するたびに、型を変換するためだけの冗長なコードが何十行も量産される。
「UserId を int に戻して、それをまた AccountId にラップして、バリデーションを通すために別のオブジェクトに変換して……」
画面にテキストを1行出すだけで、数日間のレビューと果てしない引数の引き回しが発生する。ビジネスの要求を満たす機能実装は1ミリも進まず、開発者は「オブジェクトの詰め替え作業」だけで1日を終える。これのどこが「ビジネス価値の最大化」なのか。
継承とインスタンスの無駄遣い：メモリを食い潰す肥大化アーキテクチャ
この手の自己満足設計の真の恐ろしさは、開発速度の低下だけではない。システムのリソースを容赦なく食い潰す点にある。
無知な設計者が作る値オブジェクトの山は、クラスの継承構造も、ガベージコレクション（GC）のコストも何一つ考慮されていない。
1回のリクエストを処理する間に、中身はただの文字列や数値に過ぎないラッパーオブジェクトが何千、何万個とヒープメモリ上に生成され、破棄される。
大量のデータをCSVエクスポートするバッチ処理を走らせた瞬間、メモリ使用率は右肩上がりに跳ね上がり、GCが頻発してCPU使用率が100%に張り付く。そして最後は OutOfMemoryError でプロセスが憤死するのだ。
「DDDに則って綺麗に書きました！」と誇らしげに報告してくる若手に、「じゃあ、この処理でインスタンスが何個生成されて、どれだけメモリを無駄遣いしているかプロファイラで見たのか？」と問い詰めると、誰も何も答えられない。
オブジェクト指向の基本である「データ構造とメモリコストのバランス」すら理解していない人間が、設計思想を語るなど片腹痛い。
シンプル・イズ・ベストを理解しろ：ドメインを縛るな、コードを削れ
DDDの本質は、クラスをたくさん作ることでも、複雑なレイヤー構造で自分たちの首を絞めることでもない。「ビジネスの複雑さに立ち向かうために、ソフトウェアの関心事を整理すること」だ。
本当に複雑で、将来にわたって保守が必要な「コアとなる業務ロジック」にだけリソースを割けばいいのだ。
- たかがCRUD（作成・読み取り・更新・削除）で終わるような管理画面に、値オブジェクトもリポジトリ層も不要だ。SQLで直接引いてそのまま画面に出せ。
- 単なる識別用のIDに、いちいちラッパークラスを作るな。プリミティブ型の型定義（TypeScriptのtypeエイリアスやGoの型定義など）で十分に事足りる。
- 複雑なクラス階層を作る前に、まず関数の入出力をシンプルにしろ。
優れたエンジニアが書いたコードは、驚くほど読みやすく、薄く、無駄がない。誰が見ても数秒で何をしているかが分かる。
一方で、三流のエンジニアが書いたコードは、分厚い抽象化の壁と無数のクラスの迷宮に覆われ、動かすためだけに膨大なメモリとCPUを浪費する。
教科書の用語に惑わされるな。現場で求められているのは、お前のオナニー設計ではなく、ビジネスの変更に耐えうる「シンプルで強靭なコード」だ。
新しい言葉をありがたがる暇があるなら、不要なクラスを1行でも多く削れ。シンプル・イズ・ベストを骨の髄まで理解しろ。
