dackdive's blog

新米webエンジニアによる技術ブログ。JavaScript(React), Salesforce, Python など

IDDD本もくもく読書会メモ#5(第10章 集約)

メモが滞ってる。。。第10章「集約」のメモを。

過去メモ
教材

CodeZine の記事 も第9章から更新が止まってしまっていてつらい。

メモ

10.2 ルール:真の不変条件を、整合性の境界内にモデリングする

  • 不変条件:常に整合性を保っている必要のあるビジネスルールのこと
  • 不変条件について議論する際の整合性は、トランザクション整合性のことを指す
  • 集約はトランザクション整合性の境界

整合性の境界の論理的な意味は、「その内部にあるあらゆるものは、どんな操作をするにかかわらず、特定の不変条件のルールに従う」ということだ。

10.3 ルール:小さな集約を設計する

  • モデルの一部分をエンティティとしてモデリングしたくなったらどうするか
    • その部分自体が今後も変わり続けるものなのか、あるいは変更したくなったときに丸ごと置き換えれば済むのか考える
    • 丸ごと置き換えられるならエンティティではなく値オブジェクト
  • ユースケースを鵜呑みにするな

10.4 ルール:他の集約への参照には、その識別子を利用する

  • 集約の合成構造?
  • 集約から別の集約(へのルート)への参照を持つのはOK
  • 1つのトランザクションで参照する側とされる側の両方を更新してはならない
  • 集約そのものへのポインタではなく、一意な識別子へのポインタを保持する
    • Product ではなく ProductId (値オブジェクト)を持つ

10.5 ルール:境界の外部では結果整合性を用いる

  • ひとつの集約上でコマンドを実行するときに、他の集約のコマンドも実行するようなビジネスルールが求められるのなら、その場合は結果整合性を使う
  • 一方のインスタンスが変更されてから、もう一方のインスタンスが変更されるまでの遅延が、どの程度許容されるかをドメインエキスパートにたずねてみよう
  • 現実的な手段としては、トランザクションの最後にドメインイベントを発行する
  • 誰の役割かを考える

10.6 ルールに違反する理由

10.7 発見による知見の獲得

  • 例:バックログアイテム:タスク = 1 : n の関係にある
  • 一般的な利用シナリオを頭に浮かべながら試算する、という話が書かれている
  • バックログアイテムの状態とタスクの残作業の総計は結果整合性にすべきか?
    • -> タスクの数がどれだけあっても、バックログアイテムの状態が変わるのは、常に最後の見積もりになる
      • バックログアイテムの状態が変わらない限り version が変わらないので、結果整合性でなくロックしても問題ない
  • メモリの消費

10.8 実装

  • 集約のパーツは可能な限り、エンティティではなく値オブジェクトにする
public class Product extends ConcurrencySafeEntity {
    private Set<ProductBacklogItem> backlogItems;
    private String description;
    private String name;
    private ProductDiscussion ProductDiscussion; // VO
    private ProductId productId; // VO
    private TenantId tenantId; // VO
}

Q

  • 誰の役割かを考えてトランザクション整合性か結果整合性かを決める、というのは絶対なの?
    • -> あくまで指針の1つと捉えておくのが良い


資料