高負荷トランザクションでのドメインモデル

高負荷なトランザクションが予想される処理に対しては、パフォーマンス重視の処理方法が求められる。これには、以前DataMapperを最適化することでデータアクセスの効率を上げれることは書いた。更新系の場合、このデータアクセスの効率化以外にもうひとつ厄介なデッドロック対策を行う必要がある。
デッドロック対策は効率的な方法で100%防ぐ方法はなかなか難しいが、リソースのアクセス順序をそろえるなどで運用上許容できる偶発的なレベルまで抑えることが１つの目標となる。
ただ、このアクセス順序をそろえて処理をすることがかなり難しい。高負荷のテーブルだけピックアップして考えるなどの工夫をしても実際のデータ処理順とアクセス順が一致しないことは多々あり大変である。
ドメインモデルで作成した場合はどうであろう。ドメインモデルでのデータアクセスはDataMapper経由で行われるが、このDataMapperを個々のクラスではなく、まとまったクラス群や関心事に分離されたドメインモデル単位で作成することができる。また、DataMapperはドメインモデルでの処理順序に依存しないため、任意の順番でデータアクセスさせることができる。*1この2点を組み合わせてDataMapperを作成すると、リソースのアクセス順をそろえてデータアクセスを行うことが実現できる。

高負荷トランザクションでのドメインモデルは一般的には不向きというイメージがあるかもしれないが、データ処理順序とアクセス順が切り離されていることによってデータアクセスを最適化できるメリットがある点は強調しておきたい。

*1:DataMapperではないがドメインモデルでのビジネスロジックの実装（７）に「関心事に分離されたドメインモデル」単位のデータアクセスの例がある