毎朝、ChatGPTの「毎日モデリング問題」で出してもらった問題と解説を読んでいます。
DDDの用語は知っているつもりでも、コードを見ると「これってEntity？ Value Object？」「このバリデーション、どこに書く？」で迷う。以前は、AIのコードをレビューできずに困ったこともあります。
本で用語を知っていても、いざ設計するとなると、何から考えればいいのか分からなくなる。そこで、問題と解説を読む時は、どこから考え始めているかも見ています。
設計で迷った時に戻ってこられるよう、解説で見ているところを10個にまとめました。
いきなりクラスやテーブルから考えていた
以前は、問題を見ると、いきなり「Userテーブル」「Orderクラス」を考えていました。どんな項目を持たせるか、何と何を関連づけるか。
そのまま進めると、データを入れて取り出す形は考えられても、「この状態にしてはいけない」というルールをどこで守るのかが見えなくなっていました。
「Userクラスを作ろう」と思ったら、いったん「誰が何をしたいのか」「その時、何を守らないといけないのか」へ戻ります。いきなりクラスから入ると、どうしてもデータの項目を並べる方へ頭が行ってしまいます。
問題・解説で確認するモデリングの10ステップ
チャットで出してもらった考え方を、自分用に並べたのがこの10個です。問題と解説を読みながら順に見て、途中で話が合わなくなったら前へ戻って考えます。
① Use Case（誰が何をする？）
↓
② Domain Event（何が起きた？）
↓
③ State（何がどう変わる？）
↓
④ Invariant（何を壊したらダメ？）
↓
⑤ Entity / Value Object（個体が重要？値が重要？）
↓
⑥ Aggregate（一緒に守るのはどこまで？）
↓
⑦ Aggregate間の協調（別の集約とはどうつなぐ？）
↓
⑧ Transaction / 排他（途中で失敗したら？同時に操作されたら？）
↓
⑨ Bounded Context（同じ言葉でも、仕事が違うと意味が変わる？）
↓
⑩ Scenario Validation（具体的な場面で考えると？）
① Use Case（誰が何をする？）
「注文を確定する」「クーポンを使う」。まず、誰が何をしたいのかを考えます。「DBにレコードを追加する」まで頭が進んでいたら、その前に、業務で何をしたいのかへ戻ります。
② Domain Event（何が起きた？）
「注文が確定した」「在庫が引き当てられた」。操作したあとに何が起きたのかを、過去形で書きます。そこから「次に何をする？」「どこから別の機能の仕事になる？」と考えていきます。
③ State（何がどう変わる？）
何かが起きた時、状態がどこからどこへ変わるのかを見ます。例えば、キャンセル済みの注文まで発送済みに変えられてしまったら困る。そういう、通してはいけない状態の変化がないかを考えます。
④ Invariant（何を壊したらダメ？）
「在庫より多く注文を受けない」「割引しても合計金額は0円以上」。
こういう、必ず守るルールは何かを考えます。クラスの形を決める前に、まず何を守るのかをはっきりさせます。
⑤ Entity / Value Object（個体が重要？値が重要？）
内容が変わっても、同じ注文としてIDで追いたいのか。それとも、金額と通貨のように、値が同じなら同じものとして扱いたいのか。そこを考えます。
前者がEntity、後者がValue Objectです。Value Objectは不変なものとして扱い、値を変えたい時は別の値へ置き換えます。名前から決めるより、どう扱いたいものなのかを先に見ます。
⑥ Aggregate（一緒に守るのはどこまで？）
さっきのルールを守るために、どこまでを一つのトランザクションで扱うかを考えます。
何でも一つにまとめると大きくなりすぎるし、分けすぎると、一緒に守りたいルールを守れなくなることもある。「ここはまとめて変更しないと困る」という範囲はどこなのか。そこを見ていきます。
一つにまとめた結果、更新がぶつかったり、処理が重くなったりしないかも見ます。
⑦ Aggregate間の協調（別の集約とはどうつなぐ？）
一つの操作が複数の集約にまたがったら、それぞれが守るルールと、全体の処理を調整する役割を考えます。
ここでは「すぐに両方が揃わないと困るのか」「少しあとで反映されてもよいのか」を確認します。その業務の条件を見て、ドメインサービスやイベントをどう使うか、結果整合性で進められるかを考えます。
⑧ Transaction / 排他（途中で失敗したら？同時に操作されたら？）
二人が同時に同じデータを更新したらどうなるか。処理の途中で失敗したら、どこまで戻すのか。順調に進む時だけ考えていると、この辺りが抜けそうです。
競合を見つけて弾く楽観ロックにするのか、先にロックして待たせる悲観ロックにするのか。すでに終わった処理を、別の処理で埋め合わせる補償トランザクションが必要なのか。失敗した時の扱いまで確認します。
⑨ Bounded Context（同じ言葉でも、仕事が違うと意味が変わる？）
例えば「商品」でも、販売では価格や販売期間が気になるし、物流では重量や梱包サイズが気になります。
同じ名前だからと一つのモデルにまとめる前に、どの業務の中で使う言葉なのか、その業務が何を担当するのかを考えます。モデルが通用する言葉と責任の範囲を、ここで確かめます。
⑩ Scenario Validation（具体的な場面で考えると？）
最後に、具体的な場面を頭の中や図でたどってみます。在庫が足りない、同時に決済される、途中でタイムアウトする。そういう時も、このモデルで扱えるのか。
正常に進む時から失敗する時まで、一つの流れとしてチェックします。
ChatGPTに毎日の問題を出してもらう
ChatGPTには、架空の業務要件を問題として出してもらっています。
普段書いている業務システムばかりだと、見る範囲も偏りがちです。題材を変えると、何を守るかも変わります。
朝は、その問題と解説を読んで、どこに目を向けてモデルを考えているのかを見ています。具体的な業務があると、「この場合は何を守るんだろう」と考えるきっかけになります。
例えば、経費の「承認済み」と「支払済み」を分けて見る
ChatGPTが出した学習用の題材に、経費精算の申請・承認・支払がありました。State、Entity / Value Object、Bounded Contextをつなげて考える問題です。
申請が「承認済み」になっていても、まだお金が支払われたとは限りません。この例では、承認が通ったことと、支払が終わったことを分けて見ます。
| 観点 | 問題・解説で見るところ |
|---|---|
| State | 下書き・申請済み・承認済みなどの状態で、どの操作ができるか |
| Entity / Value Object | 同じ申請をIDで追うことと、金額・通貨を値として扱うことの違い |
| Bounded Context | 申請の承認、支払の実行、会計処理を、どの業務の責任として見るか |
「承認済みだから、もう終わり」としてしまうと、支払の状態が見えなくなります。同じ申請をIDで追う話も、金額を値として扱う話も、支払を誰が進めるかという話も、この一つの流れの中にある。こういう例だと、各用語が何を区別するために出てくるのかが見えます。
用語を知っている状態から、考える順序を揃える
解説を読んで理解できても、自分で要件からモデルを考えられるかといわれると、まだ迷います。
なので、この10個は、設計で迷った時に戻ってくるためのメモです。
「誰が何をしたい？」「何が変わる？」「何を守る？」
クラス名を考え始める前に、まずこの順番から確認します。
確認した情報
確認日: 2026年9月28日
- Eric Evans: DDD Reference：Entity、Value Object、Aggregate、Bounded Contextなどの用語。PDFの本文11〜16ページにEntity・Value Object・Service・Aggregateの定義がある。
図は、ChatGPTの「毎日モデリング問題」で提示された考える順序を、自分用にまとめたものです。
コメント