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

実践ドメイン駆動 第4章メモ

開発 DDD

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

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

実践ドメイン駆動設計

実践ドメイン駆動設計

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

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

  • DDDの大きな利点の一つが、特定のアーキテクチャに依存しない
  • 4.1はインタビュー
  • 4.2はレイヤ
    • 厳密なレイヤ化アーキテクチャ
      • 直下のレイヤしか結合を認めない
    • 緩やかなレイヤ化アーキテクチャ
      • 下位にあるどのレイヤとの結合も許可する
    • 下位のレイヤが、上のレイヤとゆるく結合していることもある => ただしあくまでもオブザーバやメディエイターパターンの実装手段
    • ユーザインタフェースレイヤにはドメインロジックを含めてはいけない
      • バリデーションはどうかという声もあるが、ユーザインタフェースにおけるバリデーションとドメインモデルでのバリデーションは別の種類
    • アプリケーションサービスはアプリケーションレイヤに位置する。ドメインサービスとは異なってドメインロジックを持たない
      • 口座間のやりとりはしない、口座間のやりとりをした結果をメールで通知するのがアプリケーションサービスに当たる?
      • 一例で文字列のtenantIdを扱わず、TenantIdクラスのインスタンスを生成しているのは値オブジェクトかなにかを扱ってるということ?
      • 一例よりも複雑になるようであれば、ドメインロジックがアプリケーションサービスに漏洩している兆候
    • 伝統的なレイヤ化アーキテクチャではインフラストラクチャが最下層
      • 永続化やメッセージングなどがここに含まれる
    • 依存関係逆転の原則
      • 上位のモジュールは下位のモジュールに依存してはならない。どちらかのモジュールも抽象に依存すべき
      • 抽象は実装の詳細に依存スべきではない。実装の詳細が抽象に依存スべき
    • 例のどこがDIPなのかいまいちわからん……先ほどはTenantIdを渡されていたがTenantを渡してる点?
  • 4.3はヘキサゴナルアーキテクチャ(ポートとアダプターアーキテクチャ
    • 対象性を生み出すためのスタイル
    • クライアントからの入力をアダプタが変換し、内部のアプリケーションのAPIに合わせた形式にする。同時にシステムからの出力の仕組みも様々な形式を切り替えることが出来る。入力と同様に出力結果を変換するアダプタをつくる
    • 依存性の注入を使ったら、ポートとアダプタースタイルの開発に沿ったアーキテクチャを作りがちになる
    • 一般的な考え方と違い、システムを外部と内部の2つの領域に分ける考え方
      • 外部がさまざまなクライアントからの入力を受け付ける。また永続化されたデータを取得する仕組みを提供したりする
      • アダプターが外部と内部を結びつける
      • ポートにこうあるべきという厳密な定義はない(例だとHTTPだったりAMQPだったり)
    • アプリケーションの境界はユースケースの境界、ユースケースを造るときはアプリケーションの機能要件を基準にしなければいけない
    • ポートを自分自身で実装することはおそらくない
    • ヘキサゴナルアーキテクチャの大きな利点 => テスト用のアダプタが簡単に作れる
    • たしかに読んだ感じヘキサゴナルアーキテクチャには魅力を感じるが、ドメインサービスやドメインモデルとの関わりがいまいち。ヘキサゴナルアーキテクチャを用いるとドメインモデルやドメインサービスを中に封じ込めることができる? アプリケーションサービスは?
  • 4.4 はSOA
    • わりと曖昧な話
    • ひとつのビジネスサービスと一つのサブドメインや境界づけられたコンテキストを定義することはイコールではない

ここらで一旦止め。手で書きながら読むともうちょっと納得できるかも。

raydive.hatenablog.jp

raydive.hatenablog.jp

raydive.hatenablog.jp