実践ドメイン駆動設計 (Object Oriented Selection)
- 作者: ヴァーン・ヴァーノン,高木正弘
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/17
- メディア: 大型本
- この商品を含むブログ (2件) を見る
- 作者: ヴァーン・ヴァーノン
- 出版社/メーカー: 翔泳社
- 発売日: 2015/03/19
- メディア: Kindle版
- この商品を含むブログを見る
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
- 作者: エリック・エヴァンス,今関剛,和智右桂,牧野祐子
- 出版社/メーカー: 翔泳社
- 発売日: 2011/04/09
- メディア: 大型本
- 購入: 19人 クリック: 1,360回
- この商品を含むブログ (130件) を見る
- DDDの大きな利点の一つが、特定のアーキテクチャに依存しない
- 4.1はインタビュー
- 4.2はレイヤ
- 厳密なレイヤ化アーキテクチャ
- 直下のレイヤしか結合を認めない
- 緩やかなレイヤ化アーキテクチャ
- 下位にあるどのレイヤとの結合も許可する
- 下位のレイヤが、上のレイヤとゆるく結合していることもある => ただしあくまでもオブザーバやメディエイターパターンの実装手段
- ユーザインタフェースレイヤにはドメインロジックを含めてはいけない
- バリデーションはどうかという声もあるが、ユーザインタフェースにおけるバリデーションとドメインモデルでのバリデーションは別の種類
- アプリケーションサービスはアプリケーションレイヤに位置する。ドメインサービスとは異なってドメインロジックを持たない
- 伝統的なレイヤ化アーキテクチャではインフラストラクチャが最下層
- 永続化やメッセージングなどがここに含まれる
- 依存関係逆転の原則
- 上位のモジュールは下位のモジュールに依存してはならない。どちらかのモジュールも抽象に依存すべき
- 抽象は実装の詳細に依存スべきではない。実装の詳細が抽象に依存スべき
- 例のどこがDIPなのかいまいちわからん……先ほどはTenantIdを渡されていたがTenantを渡してる点？
- 厳密なレイヤ化アーキテクチャ
- 4.3はヘキサゴナルアーキテクチャ（ポートとアダプターアーキテクチャ）
- 対象性を生み出すためのスタイル
- クライアントからの入力をアダプタが変換し、内部のアプリケーションのAPIに合わせた形式にする。同時にシステムからの出力の仕組みも様々な形式を切り替えることが出来る。入力と同様に出力結果を変換するアダプタをつくる
- 依存性の注入を使ったら、ポートとアダプタースタイルの開発に沿ったアーキテクチャを作りがちになる
- 一般的な考え方と違い、システムを外部と内部の2つの領域に分ける考え方
- 外部がさまざまなクライアントからの入力を受け付ける。また永続化されたデータを取得する仕組みを提供したりする
- アダプターが外部と内部を結びつける
- ポートにこうあるべきという厳密な定義はない（例だとHTTPだったりAMQPだったり）
- アプリケーションの境界はユースケースの境界、ユースケースを造るときはアプリケーションの機能要件を基準にしなければいけない
- ポートを自分自身で実装することはおそらくない
- ヘキサゴナルアーキテクチャの大きな利点 => テスト用のアダプタが簡単に作れる
- たしかに読んだ感じヘキサゴナルアーキテクチャには魅力を感じるが、ドメインサービスやドメインモデルとの関わりがいまいち。ヘキサゴナルアーキテクチャを用いるとドメインモデルやドメインサービスを中に封じ込めることができる？ アプリケーションサービスは？
- 4.4 はSOA
- わりと曖昧な話
- ひとつのビジネスサービスと一つのサブドメインや境界づけられたコンテキストを定義することはイコールではない
ここらで一旦止め。手で書きながら読むともうちょっと納得できるかも。
