DDD
ドメイン駆動設計

ちょっとずつ読むドメイン駆動設計 第ニ部 モデル駆動設計の構成要素 第六章 ドメインオブジェクトのライフサイクル9(リポジトリ その3)

More than 1 year has passed since last update.

その1その2の続きです。

リポジトリに対して問い合わせる

クエリにどんなものがあるか?
- 識別子を用いてエンティティを取り出す
- 特定の属性やパラメータの複雑な組み合わせを用いてオブジェクトのコレクションを要求
- 値の範囲(日付の範囲など)に基いてオブジェクを選択
- 何らかの計算を実行
などなど

クライアントのコードはリポジトリの実装を無視するが、開発者はそうではない

アプリケーション層などリポジトリを使う側から見れば実装がどうなっているか気にする必要がないが、もちろん裏側の実装は開発されなければならない。。。当然ですよね。

インフラストラクチャにありがちなパフォーマンス問題やメモリ問題などの問題には取り組まなければならず、

カプセル化されたふるまいを使用した際の影響について、理解する必要がある(第二部第六章より)

リポジトリを実装する

クライアントコードが、データの格納場所に関わらず同じになることだ。(第二部第六章より)

裏でどんな実装をしても、使う側からみたら同じになることが理想ですね。

以下、実装で覚えておくべき懸案を整理しておきます。

  • 型は階層における抽象基底クラスでも構わない

データベースでは、多態性を実現することは困難ですが、型に多態性を求めてもいいとのことです。もちろん、データベースの制約をなんとかする必要があるのはその通りですね。

  • クライアントから切り離す利点を活かす

クライアントのコードを変えずに、性能問題に取り組んだり、永続化の戦略を変更したり、さらに、テストにモックを利用することもできますね。

  • トランザクション制御をクライアントに委ねる

トランザクションの制御はインフラストラクチャで行うのではなく、アプリケーション層などのクライアントで実施すること。

フレームワーク

SpringやRailsなどアーキテクチャフレームワークの選択には注意。
特にフルスタックのフレームワークでは、インフラストラクチャ層までカバーしているものもあるが、それがリポジトリパターンと同等に使えるかどうかが問題になりそう。

リポジトリパターンと同等に使えない場合、フレームワークをそのまま使うか、ドメイン駆動に沿うように頑張るか。。。

一般的に言えることだが、使っているフレームワークとは争わないこと。フレームワークと対立してしまった時には、ドメイン駆動設計の基本を保ちながら、詳細は捨て去る方法を模索すること。ドメイン駆動設計の概念とフレームワークの概念に似通った部分がないか探すこと。(第二部第六章より)

どうしてもドメイン駆動設計の概念をきちんと利用していこうと思ったら、そういうフレームワークを選択しないことを一度検討した方が良さそうですね。

明日さらにリポジトリを読んでいきます。