遅延ロードを避ける
シンプルなドメインモデル実装
ドメインモデルを作成するときに、遅延ロードを利用すると、データアクセスのコストやロック、トランザクションなど様々なことを意識する必要がありかなり難しくなります。ドメインモデル実装が難しいという方の意見としても遅延ロードを上げる方が多いように思います。逆に考えれば、遅延ロード機能を利用しなければかなりシンプルに実装することが可能になるということです。
リーズナブルなデータアクセス
遅延ロードを利用すると、関連データをアクセス時までモデルに読み込みことを保留することで不必要なメモリ消費や余計なデータアクセスを避けるメリットがあります。逆に遅延ロードを利用しないと大量のメモリと多くのデータアクセスを引き起こす可能性があります。なので、遅延ロードを避けるのであれば、この点についてうまい方法が必要になります。明らかに不必要なデータを読み込むことを避け、必要と予想されるデータをリーズナブルに取得する方法が必要だということです。
データマッパーの最適化
あるモデルに対するデータアクセスのシナリオを考えた場合、ユースケース（機能）によって様々なバリエーションをあります。たとえば、商品であれば商品編集シナリオ、商品注文編集シナリオ、商品検索シナリオなどが考えられます。これを１つのデータアクセスで対処しようとするとやはり無理があるのでそれぞれのシナリオで最適化する必要があります。たとえば、商品編集シナリオであれば編集対象の商品とその商品が関連する品目、商品注文編集シナリオでは対象の商品と商品の価格ルール、商品検索シナリオであれば検索商品のみ取得するなどそれぞれ関連するデータの取得範囲を最適化します。このようなことは個々のシナリオでデータマッパーを作成することで簡単に実現することができます。
さらに、共通化が若干犠牲になりますが、シナリオに対してドメインモデルをカスタマイズ（関心事に分離されたドメインモデル）することによって、属性レベルやグルーピングされたデータの利用などかなり最適化されたデータアクセスが可能になります。
スケーラビリティのあるモデル
ただ、多くのデータマッパーやカスタムのドメインモデルを作成することはあまり行いたくはありません。多少パフォーマンス効率が悪くても多くのシナリオで共通性の高いデータマッパーを利用するほうが開発効率としてはリーズナブルです。このバランスを適切に取るためには、パフォーマンスの最適化は初めから行うのではなく必要になったら容易に対応できるモデル構造になっていれば問題ないわけです。たとえば、商品の一覧検索において、すべての項目を取得する共通に用意したデータマッパーをはじめは利用しておき、パフォーマンスが必要になった時点で検索項目に特化した項目のみを取得するデータマッパーに置き換えるだけで対象できるようにするということです。
