Value Object・Entity・Aggregate - DDD のモデル構成要素
EC サイトの注文に「代金引換で支払う注文は、明細の合計金額が引換の上限額を超えない」という規則を置いたとします。明細を書き換えられる経路が複数あると、規則を検査しない経路から上限を超えた注文ができます。同姓同名の顧客を同じ人として扱う取り違えも、値の比べ方を決めていないと起きます。 ...
EC サイトの注文に「代金引換で支払う注文は、明細の合計金額が引換の上限額を超えない」という規則を置いたとします。明細を書き換えられる経路が複数あると、規則を検査しない経路から上限を超えた注文ができます。同姓同名の顧客を同じ人として扱う取り違えも、値の比べ方を決めていないと起きます。 ...
注文の画面にも、値引きの条件にも、請求書にも「合計」が出てきます。どれも同じ注文に付く同じ語なので、注文のモデルに total を 1 つ持てば足りるように見えます。 ...
Repository とは、Aggregate(集約。規則を一緒に守るオブジェクトのまとまり)を 1 つの単位として保存・復元する仕組みで、呼び出す側からはメモリ上のコレクションのように見えます。注文と明細のように、まとめて検査すべき規則を持つデータを DB(データベース)に保存する時に、明細だけを書き換える経路を塞ぐために使います。 ...
Domain Event とは、ドメインの中で既に起きた出来事を表すオブジェクトです。過去の記録なので通常は不変(作った後に値を変えない)で、出来事が起きた時刻と、関与したエンティティの識別子を持ちます。 ...
外部の決済サービスが、支払いの status に REVIEW(不正検知の審査中)という値を 1 つ足しました。呼び出す側のコードは例外を 1 件も出さず、そのまま動き続けます。以下は、決済サービスの値を 4 か所でそのまま読むコードと、値を 1 か所で自分たちの語に置き換えるコードに、REVIEW の支払いを 1 件ずつ渡した結果です。決済サービスとコードは、本記事のために書いた架空のものです。 ...

前書き:GolangでValue Objectを作りづらい 2025年の抱負で「ブログのアウトプットを増やす(リンク先の末尾を参照)」と宣言したので、早速アウトプットします。 今回取り扱うValue Objectとは、主に以下のような特徴を持ちます(本記事の本題と関係ない要素は意図的に省略しています) ...