「コードで理解するDDDの戦略的設計・戦術的設計のつながり」のセミナーに参加しました

「コードで理解するDDDの戦略的設計・戦術的設計のつながり」に参加したので、メモを共有します。

ddd-community-jp.connpass.com

DDDの概略

• 原典
  • DDD Reference – Domain Language

知識

• 問題領域の知識
  • 何を解決するか？
• 解決領域の知識
  • どうやって解決するか？

レイヤアーキテクチャー以外のアーキテクチャ図

• ヘキサゴナルアーキテクチャからオニオンアーキテクチャ（DDDを意識）、クリーンアーキテクチャへ
  • 1個のサービスが1個の円の図を表す。円同士が円の外側で通信する。（マイクロサービスを意識）

要件を2種類に分けて考える

• ユースケース
  • 頻繁に変わる
• ビジネスルール
  • あまり変わらない

ドメインオブジェクト

エンティティ

• 可変
• IDを持つ
• IDで比較
• １テーブル

値オブジェクト

• 不変
• 持たない
• 値で比較
• テーブルの値

ドメインサービス

• エンティティにできないもの
  • 例えば、空いている予約の確認
    • 個々の予約モデルだけでは判定できない
  • 極力使わない

集約

• 整合性を保つ最低限の単位
• トランザクションの設計をしないと集約の設計はできない
• 1リポジトリ：１集約
  • 集約のルートは１つ
  • レポジトリはルートに対して作成
• 集約間でインスタンスの参照はしない
  • 集約はリポジトリ単位で取得する
• 違うコンテキストで１つのテーブルを参照はしない

集約をまたぐ更新

以下の２つの方法がある。

ドメインイベント

• メリット
  • 構造が美しい
• デメリット
  • エンティティを更新したときに裏でイベントが発火していることをプログラマーは把握しづらい。

ユースケース層で複数集約に更新

• メリット
  • 他の集約も更新していることがソースをみればわかる。
• デメリット
  • 参照するリポジトリが多くなる
  • 複数集約に更新する処理の実装をプログラマーに委ねることになる（強制ができない）

CQRS

• 更新メソッドで更新したエンティティを返さない
  • 更新と取得と１メソッドでやらない
  • でも画面側でどうしようもない場合もある
• ポリシーをしっかり決める
  • 松岡さんはIDを返すそうです（オブジェクト自身を返すのはやり過ぎ）

その他メモ

• DDDでやっていると、必ずしも原理原則に沿うことがベストではないこともある。メリットデメリットを考慮して妥協することもある。
• 複数コンテキスト
  • Cient→ゲートウェイで複数コンテキストと通信
    • ここにはロジックを持たせない
• Lombok
  • getter/setterなど冗長なコードを自動生成してくれるJavaのライブラリ。