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

実践ドメイン駆動 3章メモ

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

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

実践ドメイン駆動設計

実践ドメイン駆動設計

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

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

  • 2章が問題空間の評価、3章が解決空間の評価
  • DDDにとりかかるまえに、プロジェクトの現状を表すコンテキストマップを描く
  • 図のUはUpstream、DはDownstream
  • DDDを実践するならシンプルな図はプロジェクトごとに必要
    • 巨大な泥団子と結合を求められる場合がある
    • そういうものを保守しているチームは、そのコンテキストのAPIにこちらがしたがってるかぎりこちらの方針はきにしないし相手にとってマップは無意味
    • マップを描くときに、彼ら(巨大な泥団子を保守しているチーム)との関連をきっちり反映させておく必要がある
  • そこから得られる知見が必要、かつチーム間のコミュニケーションが必要になるか判断できる
  • コンテキストマップはコミュニケーションツールとして使える
  • ほぼゼロの状態からはじめるのだったとしても、そのプロジェクトについての仮定をマップ形式にしておけば、* 別の境界づけられたコンテキストについて考えるきっかけになる
  • コンテキストマップは現存する地形をとらえる、将来の姿ではない。風景が変わってきたら、その時点の状況にあわせて更新する
  • コンテキストマップはメンバーが常にそれを見て議論できるようにしておく必要がある
  • 境界づけられたコンテキストとそれぞれのプロジェクトチームとの関係
    • パートナーシップ
    • 共有カーネル
    • 顧客/供給者の開発
    • 順応者
    • 腐敗防止層
    • 公開ホストサービス
    • 公表された言語
    • 別々の道
    • 巨大な泥団子
  • 図3−2にいたるコンテキストマップの書き方がよくわからない
    • なんでこの形になったのか
  • コンテキストマップは一度で完璧に出来上がるものではない
  • どれをコアドメインにするかによって、ある視点ではコアドメインだったものが支援サブドメインになることもある
  • 新たなコアドメインが図の一番上にあるものではない(システムのアーキテクチャ図ではない)
  • コアモデルがその他のモデルの下流として働くことを視覚的に示している
  • 上流のモデルが下流のモデルに影響をおよぼす
  • 公開ホストサービス
    • RESTなリソースとかメッセージング
    • /usr/01みたいな?
  • 公表された言語
    • データをどうやって表現するか?
  • 腐敗防止層
    • ドメインサービスを下流のコンテキストで定義して、それぞれの型の腐敗防止層とする
    • 腐敗防止層はリポジトリインターフェイスの中に入れることもできる
    • とってきたデータをそのまま使うのではなく、適切なマッピングドメインオブジェクトをつくる
    • 自立性を確保するためには、依存するオブジェクトの状態をローカルシステム側に保持する
    • ローカルのドメインオブジェクトを作って外部のモデルをそれに変換し、ローカルのモデルに必要な最小限の状態だけを保持する
  • リモートモデル側の変更を同期させるには、リモートシステム側からのメッセージによる通知で十分
    • つまりイベント?
    • データの動機を最低限に抑えるだけでなく、概念を適切にモデリングするという意味もある
  • 存在しないディスカッションを使おうとした場合などリソースが使えないことを想定した設計にする必要がある
  • 結果整合性での対応は正常な状態の一つ、きちんとモデリングするべき
  • 結果整合性を活用するためにドメインイベントとイベント駆動アーキテクチャを使う必要がある
  • 今回の場合だと、使えなくなる場合を明確にする => Stateパターンで実装

後は実装面の話などもシーケンス図で記載されていたり。わかりやすい部分もわかりずらい部分もあり、まだ咀嚼しきれてない。