実践ドメイン駆動設計 (Object Oriented Selection)
- 作者: ヴァーン・ヴァーノン,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログを見る
2.9
- 唐突にコラボレーションという単語が出てくる
- ここでは境界づけられたコンテキストといってるので、一種の機能と見ればよい？
- ユーザとパーミッションは含めるべきでない
- ユーザの役割は考えるべきだが、ユーザが何者かなどはフォーラムを考えるうえで不要
- と書いたけど、その後で役割（ロール）もまた切り離す必要があるとなっている
- フォーラムが知っておくべきこと
- ある投稿者が今何をやっているか
- これまで何をやってきたか
- もともと何をやろうとしているのか、いまいち文意が取れないがフォーラムというサブドメインを考えたときに何を考えるかという話をしている？
- ユーザやパーミッション/ロールは、コラボレーションコンテキストから切り離す必要がある
- これはセキュリティサブドメインとして分離
- 「チームが次に扱うコアドメインでも……」でロールベースのアクセスを扱う必要があるのはなぜか？
- フォーラム（これもおそらくコアドメイン）を扱うのにロールが必要だから？
- ユーザやロールが支援サブドメイン・汎用サブドメインなのはわかる
- クリーンなモデリング => Big Ball Of Mud を避けられる
- チームとして 戦略的モデリングの考え方を推し進める必要がある
2.10
- ドメインは問題空間と解決空間を持つ
- 問題空間：解決すべきビジネスっ戦略上の課題を浮き彫りにする
- 解決空間：ソフトウェアをどのように実装してその課題を解決するか
- 問題空間はドメインの一部
- 解決空間は境界づけられたコンテキスト
- 各サブドメインと境界づけられたコンテキストを1対1対応するのがのぞましい
- 新規はなんとかなる
- レガシーシステムはどうするか
- アセスメントビューを使う
- 例としてERPアプリケーション
2.11
- 境界づけられたコンテキストは明示的な境界かつ、ドメインモデルがどこにぞくするのかを表すもの
- ドメインモデルはユビキタス言語をソフトウェアモデルとして表したもの
- 教会の内部ではユビキタス言語のあらゆる単語やフレーズが特別な意味を持つ
- 境界づけられたコンテキスト = 言語的境界
- あらゆる名称が唯一の意味しかもたない全部入りの巨大なモデル => 組織全体で合意形成しようという落とし穴
- すべてのステークスホルダー全員が納得する共通の意味付け => 不可能
- 図示することはできるが、図自体が境界づけられたコンテキストではない
- アカウントという用語で銀行取引コンテキストと文学コンテキストでの意味合いの違い
- コンテキスト重要
- 似てるけど微妙に意味が違う場合
- 当座預金コンテキストと普通預金コンテキスト、どちらも口座でいい
- コンテキストの違いが区別するから
- 統合の段階 => 境界づけられたコンテキスト間でのマッピングが必要
- 同ドメイン内での複数の境界づけられたコンテキストで、共通してつかわれがちな名前
- 例として書籍のライフサイクル
- DDDのモデリング => 書籍のライフサイクルの段階ごとに別の境界づけられたコンテキストを利用、コンテキストごとに書籍を表す型を用意する
- さっきのコラボレーションチームの例だと……
- コラボレーションコンテキストでは機能の利用者を役割で定義
- 認証・アクセスコンテキストではユーザの情報（名前、詳細情報）
- 役割も含まれる？
- コラボレーションで投稿者をつくるときは認証・アクセスコンテキストで適切な役割を持つユーザをチェックする、モデレーターなどの新しいコラボレーターオブジェクトを作るには、ユーザの属性の一部と役割の名前を使う
- コンテキスト間でやりとりして、適切なオブジェクトをつくるという理解でいい？
- 同じオブジェクトが複数のコンテキストに存在するようならモデリングが間違ってる
途中まで……
これだけで結構ボリューミー。もうちょっと時間さいて読まないときっつい。
