ローカル DTO

私の仲間であるThoughtBloggersをチェックしていればご存知でしょうが、私のフォウルボットの1つがヒューズを飛ばしたようです。オーストラリアの太陽が、どうやらこれらのスウェーデンモデルを焦がしているようです。

ジョンはデータ転送オブジェクトにうんざりしていますが、DTO自体が悪いものではありません。他のパターンと同様に、特定の状況では役立ちます。パターンには常に2つの側面があります。それは「方法」と「タイミング」です。実装方法を知るだけでなく、いつ使用し、いつ放置すべきかも知っておく必要があります。

彼の指摘はもっともです。私はリモートインターフェースの文脈でしかDTOについて述べていませんでしたが、パターン自体の記述でリモートの文脈を繰り返していませんでした。そして、リモートでない場合に使用したがる人々にも遭遇します。そこで、ここでそれを補うチャンスです。

DTOはデータ転送オブジェクトと呼ばれています。なぜなら、その目的は高コストなリモート呼び出しでデータを移動することだけだからです。パフォーマンスのためにリモートインターフェースが必要とする粗粒度のインターフェースを実装するための一部です。ローカルの文脈では必要がないだけでなく、粗粒度のAPIは使用が難しく、ドメインまたはデータソース層からDTOにデータを移動するすべての作業を行う必要があるため、実際には有害です。

一部の人々は、サービス層APIの一部としてDTOを主張します。なぜなら、それらはサービス層のクライアントが基盤となるドメインモデルに依存しないことを保証するからです。それは便利かもしれませんが、私はすべてのデータマッピングのコストに見合うとは思えません。私の貢献者であるランディ・スタフォードがP of EAAで述べているように、「[DTOを使用する]コストを過小評価しないでください....それは重大であり、苦痛です。おそらくオブジェクトリレーショナルマッピングのコストと苦痛に次ぐものです。」

私が耳にした別の議論は、後で配布したい場合にそれらを使用するというものです。この種の投機的な配布境界は、私が第一法則で批判しているものです。リモート境界を追加すると複雑さが増します。したがって、ランディのアドバイスを繰り返します。「ドメインオブジェクトを扱うメソッドシグネチャを持つ、ローカルで呼び出し可能なサービス層から始めます。必要なときに（もしあれば）、リモートファサードをサービス層に配置するか、サービス層オブジェクトにリモートインターフェースを実装することで、リモート機能を後から追加します。」

DTOのようなものを使用することが役立つ1つのケースは、プレゼンテーション層のモデルと基盤となるドメインモデルとの間に大きな不一致がある場合です。この場合、ドメインモデルからマッピングし、プレゼンテーションに便利なインターフェースを提供する、プレゼンテーション固有のファサード/ゲートウェイを作成するのが理にかなっています。プレゼンテーションモデルとうまく適合します。新しいボリュームでこれについてもっと話したいと思っています。これは価値のあることですが、この不一致がある画面でのみ価値があります（この場合、画面でいずれにせよ行う必要があるため、追加の作業ではありません）。

更新: ティボー・バレールは、ローカルDTOの別の目的である、マルチスレッドアプリケーションのアイソレート間での通信について私に思い出させてくれました。マルチスレッドを処理する良い方法は、アプリケーションを各領域が1つのスレッドのみを実行する分離された領域に分割することです。これにより、その領域内での同時実行制御の必要性がなくなります。これらの分離された領域間で通信する必要がある場合は、情報を転送するためのメッセージとしてDTOを使用したメッセージキューを使用します。