読者です 読者をやめる 読者になる 読者になる

実践ドメイン駆動設計 5.3メモ

開発 DDD

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計 (Object Oriented Selection)

実践ドメイン駆動設計

実践ドメイン駆動設計

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

5.4はまとめなので飛ばし。

  • 境界づけられたコンテキストを切り分けて、ユビキタス言語を見つけ出す => ドメインモデル構築に必要な概念や語彙が得られる
  • 認証・アクセスコンテキストにおいて、Userをモデリング
  • さまざまな形式で変更という言葉が出てくると、何らかのエンティティを扱っている
    • ただし変更は値を置き換える意味もある
  • 鍵となる用語「認証済み」 => 何らかの形式の検索機能を用意する必要があることを示唆 => 見分ける必要があるので識別子が必要
    • 個人情報をどう保持するかはまだ考えない
  • 言葉遣いで要件を意味あるものに出来る
  • 識別子を値オブジェクトにする => 強力な型付け
  • TenantとUserの関連がいまいちわからん……
  • 特別な振る舞いを持たないものはシンプルな属性にしておく
    • いくつか属性が考えられるが、業務的な関心ごとは置いておいて、境界づけられたコンテキストで扱う範囲のものを属性として持つようにする
    • 扱う範囲を広げすぎては行けない
  • 別コンテキストでエンティティが特定できたら、識別子が扱えるようになる
    • 例として名前からTenantを特定するとTenantIdが扱える
  • パスワードのような変更できるものは一位な識別子ではない
  • モデリングの際には、一意に識別したり、検索で他と区別したりするために必要な属性に中李目する
  • ドメインエキスパートが使う用語から操作の関数名などを決めていく
  • 認証のように単にUserを探すだけの作業ではないもの、高度なレベルでのとりまとめ役が必要 => ドメインサービス
  • 新しくモデリングに追加したものはエンティティか値オブジェクト => 変更がキーワード
  • モデリングにはオブジェクトのロールと責務を見出す側面がある
    • 一般的にドメインオブジェクトに対して行う
  • OOPではインタフェースが実装クラスのロールを定める
    • 複数オブジェクトがあれば、それらの間には共通点も相違点もあるのが普通
    • 共通部分は一つのオブジェクトに複数のインタフェースを混ぜ込むことで対応できる
  • オブジェクト統合失調症 => 処理を移譲されたオブジェクトが委譲元のオブジェクト識別子を知らない状況
  • Qi4jやロールのインタフェースをきめ細やかにする
    • インタフェースを細かくする => ユースケースに応じてロールを変えられる
    • クラス自身の振る舞いを実装するのが楽になる => オブジェクト統合失調症のおそれがなくなる
  • ドメインモデルのインタフェースは技術的な実装の詳細に影響をうけない
  • エンティティのインスタンスを造るときは、状態を完全にとらえられるコンストラクタを使い、一意に特定できるようにしておきたい
    • 識別子を引数にしたり、名前で検索したりする場合は名前を引数にしたりする
    • 不変条件を保持することもある
      • クラスの設計で、ガードをかけることができる
  • 複雑なエンティティにはファクトリをつかえる
  • バリデーションを行う理由
    • 属性やプロパティ、オブジェクトどうしの合成などが正しく設定されていることを確認するため
      • 個々では問題ないバリデーションでも、全体をみるとおかしいことがあるので、何段階かのバリデーションが必要
  • 属性/プロパティのバリデーション
    • 自己カプセル化 => 同一クラス内でもアクセサを使う
    • 筆者はこれをバリデーションとは呼びたくない模様 => 自分もあまりバリデーションとは思わない アサーションのほうがニュアンスが会ってる
    • 文字列の長さチェックはDBでもできるのでは? => DBの返すエラーメッセージをドメインの意味の通るエラーにするのがたいへん
  • オブジェクト全体のバリデーション
    • CHECKSパターンランゲージ => 遅延バリデーション
    • ドメインオブジェクトのバリデーションのほうが、エンティティよりも変更頻度が高い
    • エンティティの責務が増えすぎる => バリデーションコンポーネントにくくりだす
    • Javaなら同じパッケージ内に入れておく(private以外)
    • バリデーションクラスは仕様やストラテジを実装できる
      • すべての結果を収集する必要がある
    • クライアント側でエンティティのバリデーションが行われたことを確認するためには?
      • validateメソッドの用意 => クライアントで呼び出せる
  • オブジェクト合成のバリデーション
    • いくつかのエンティティの組み合わせが全体で妥当か?
      • バリデーターの具象サブクラスを必要な数だけ用意
      • 一連のバリデーションをドメインサービスで管理する
  • 変更の追跡
    • 必須ではない
    • ドメインイベントとイベントストアを使うと、状態変更する各コマンドについて、記録できる
    • それぞれ別のイベント型を作成
    • サブスクライバはモデルが発行するイベントを全て受信するよう登録