なんとな~くしあわせ?の日記

「そしてそれゆえ、知識そのものが力である」 (Nam et ipsa scientia potestas est.) 〜 フランシス・ベーコン

EntityとDto

EntityとDto

  • Dtoについてこれまで誤解していたことと、本来の使われ方について書く

EntityとDtoの違い

TL;DR:
  • エンティティはビジネスドメインの一部でありうる。それゆえ、それには振る舞いとドメイン内での異なるユースケースに適用される
  • DTOはある処理や他の文脈への転送のためだけに使われる。例えば、それらには振る舞いがない;つまりとても基本的で大抵標準化されている保存と取得のための関数しか実装されていない*1
長い解説
  • "Data Transfer Object(DTO)" がとても不明瞭に定義されているのに対して、"Entity" は様々な文脈で異なる解釈をされている
  • "Entity"という用語にもっとも関連のある解釈は、私の意見としては以下の3つになる:
    • エンタープライズJavaJPAの文脈において:「データベースの中で保守される永続化データを表すオブジェクト」
    • ドメイン駆動開発の文脈において(Eric Evansの発言):「属性よりもその同一性によって主要に定義されるオブジェクト」
    • クリーンアーキテクチャの文脈において(Robert C. Martinの発言):「エンタープライズ横断的に重要なビジネスルールをカプセル化したオブジェクト」

JEEやJPAコミュニティはエンティティをもっぱらデータベースのテーブルにマッピングするものとして見ている。この見方はDTOの定義に非常に近い。そしてこれがこの混乱の元になっているのかもしれない。ドメイン駆動開発の文脈においては(というのはRobert Martinの見方だが)、エンティティはビジネスドメインの一部でそれゆえに振る舞いを実装すべきなのだということだ。

Data Transfer Objectの本来の意味

  • P of EAA: Data Transfer Object
    • マーティンファウラーのサイトから
    • もともとのDTOは、リモートアクセスの呼び出しコストが高い状況において呼び出しを1つのDTOでまとめておくことで呼び出し回数を減らすことが目的だったようだ

まとめ

  • 今まで経験したJavaのアプリケーション開発では、DTOはテーブルとマッピングさせて使われることが多かったように思う。そしてそれは呼び出しをまとめるという初期の目的は失われている。たぶんEntityのような意味でDTOという名づけをするのは誤用ではないだろうか?
  • ついでに言うとDTOとDAOを作成するプロジェクトはDTOのコピーでバグがよく発生していた。それは単にビジネスロジックを書く部分がダメだっただけかもしれないが

*1:getterやsetterのこと