実践ドメイン駆動設計 (Object Oriented Selection)
- 作者: ヴァーン・ヴァーノン,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログを見る
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
- ２章が問題空間の評価、３章が解決空間の評価
- DDDにとりかかるまえに、プロジェクトの現状を表すコンテキストマップを描く
- 図のUはUpstream、DはDownstream
- DDDを実践するならシンプルな図はプロジェクトごとに必要
- 巨大な泥団子と結合を求められる場合がある
- そういうものを保守しているチームは、そのコンテキストのAPIにこちらがしたがってるかぎりこちらの方針はきにしないし相手にとってマップは無意味
- マップを描くときに、彼ら（巨大な泥団子を保守しているチーム）との関連をきっちり反映させておく必要がある
- そこから得られる知見が必要、かつチーム間のコミュニケーションが必要になるか判断できる
- コンテキストマップはコミュニケーションツールとして使える
- ほぼゼロの状態からはじめるのだったとしても、そのプロジェクトについての仮定をマップ形式にしておけば、* 別の境界づけられたコンテキストについて考えるきっかけになる
- コンテキストマップは現存する地形をとらえる、将来の姿ではない。風景が変わってきたら、その時点の状況にあわせて更新する
- コンテキストマップはメンバーが常にそれを見て議論できるようにしておく必要がある
- 境界づけられたコンテキストとそれぞれのプロジェクトチームとの関係
- パートナーシップ
- 共有カーネル
- 顧客/供給者の開発
- 順応者
- 腐敗防止層
- 公開ホストサービス
- 公表された言語
- 別々の道
- 巨大な泥団子
- 図３−２にいたるコンテキストマップの書き方がよくわからない
- なんでこの形になったのか
- コンテキストマップは一度で完璧に出来上がるものではない
- どれをコアドメインにするかによって、ある視点ではコアドメインだったものが支援サブドメインになることもある
- 新たなコアドメインが図の一番上にあるものではない（システムのアーキテクチャ図ではない）
- コアモデルがその他のモデルの下流として働くことを視覚的に示している
- 上流のモデルが下流のモデルに影響をおよぼす
- 公開ホストサービス
- RESTなリソースとかメッセージング
- /usr/01みたいな？
- 公表された言語
- データをどうやって表現するか？
- 腐敗防止層
- リモートモデル側の変更を同期させるには、リモートシステム側からのメッセージによる通知で十分
- つまりイベント？
- データの動機を最低限に抑えるだけでなく、概念を適切にモデリングするという意味もある
- 存在しないディスカッションを使おうとした場合などリソースが使えないことを想定した設計にする必要がある
- 結果整合性での対応は正常な状態の一つ、きちんとモデリングするべき
- 結果整合性を活用するためにドメインイベントとイベント駆動アーキテクチャを使う必要がある
- 今回の場合だと、使えなくなる場合を明確にする => Stateパターンで実装
後は実装面の話などもシーケンス図で記載されていたり。わかりやすい部分もわかりずらい部分もあり、まだ咀嚼しきれてない。
