バックエンド初学者はDDDには手を出すな
意見記事です。
結論
DDDを学ぶ前にモデリングを学ばなければいみがない
詳しく
DDD(ドメインモデル駆動)はその名前の通りドメインモデルを最初に定義してそこから実装に移ろうという開発手法です。ドメインモデルはビジネスの概念モデルとシステム内部のモデルを共通化することでシステムの保守のしやすさを向上させることを目的にしたものです(ビジネスは基本的にビジネスのモデルに沿って要求が発展する。そこでシステムもそのモデルと一致させれば変更対応がしやすくなるというカラクリ)。つまりモデリングスキルが必須となります。
僕も3年前からDDD本や実践DDD本を購入し、よくわからず読み進め、増田さんや成瀬さんや松岡さんの本で理解を深めてきました。DDD本のようにドメインエキスパートと対話してドメインモデル図も書いてみました。しかし、そのドメインモデル図は独自のクラス図の書き方で、他の型と紐付かないなぜか孤島のようになった型もあり、かつ実装とかけ離れていました(必死に集約どれかなとか考えてました)。
そんなときにたまたまUMLモデリングの本を読みました。
そこから、ずっと靄がかかっていたものが晴れました。予定と実績やヘッダーと明細、イベントなどモデリングパターンが頭に入ってきたとき、なぜドメインモデル図がうまく行かないのか理解しました。そもそもモデリングスキルがなかったのです。集約を最初から考えなくても概念モデリングをしたときに自然と集約は現れますし、うまい境界が見つけやすくなります。
詳細は見せられませんがUMLモデリングを学ぶ前と後のドメインモデル図です。左が前で右が後です。
そこから、オブジェクト指向の強みであるプラグインやそのデザインパターンを適応できるようになってきました。
ここで初めて気づきました。DDDはオブジェクト指向と概念モデリング両方の基礎があって初めて実践できる境地なのだと。もし最初にDDDに手を出さずにこれらを学んでいたらもっとすんなりいっていただろうと。気づくのに3年かかりました。なので皆さんには僕と同じ轍を踏まないように、この意見記事を捧げます。
その他
よくRepositoryパターンとかEntityうんぬんの話がありますが、あれはあくまでドメインモデルをシステム内部で実現するために、データベースやフレームワークの色がついていない真っ白なキャンバスを用意するためのプラクティス集です(そのキャンバス上で自由にドメインモデルを描けるように)。もしモデルよりもそちらのプラクティスのほうが興味があるのであれば、クリーンアーキテクチャの本を読むのがおすすめです。DDDという言葉を使わずに理解を深めることができます。
Discussion