DTOはビジネスオブジェクト（動作あり）と見なすことができますか？
この質問とその回答に基づいて：
ビジネスレイヤーのオブジェクトはロジックを含むDTOと同じですか？
私が聞きたいのは：
DALの代わりに、DTOを介してリモートサービス（API）からデータを取得している場合はどうなりますか？ここでの私のDTOは、間にすべての関係を持つかなり多くのビジネスオブジェクトを表しています。私が呼び出しているAPIにはBOがありますが、それは私に固有なので、必要な動作を置くことはできません。どうすればこれに対処できますか？
dTOで動作がない場合はどうなりますか？これは安っぽい
（API）<-DTO->（mappingService）<-Domain object->（domainService）<-DTO->（UI）??
選択できるアーキテクチャパターンはいくつかあります。
- [〜＃〜] dto [〜＃〜] は分散パターンであり、プロセスとリモートサービス間でデータを転送することを目的としています。目標は、単一プロセスの境界を越えるときに非効率な プロセス間関数/メソッド呼び出し の数を減らすことです。
- ドメインモデルオブジェクト は、転送と永続性をデータゲートウェイまたはマッパーに任せます。
- アクティブレコード は両方の組み合わせです。ドメインロジックと共にデータアクセスをカプセル化することを目的としています。
基本的に、DTOとドメインロジックを組み合わせると、アクティブレコードによく似ています。ドメインモデルが単純で、ドメインオブジェクトがDTOに非常に近い場合、これは実行可能なソリューションです。
ただし、その主な欠点に注意してください。
- dTOによって提供されるデカップリングから利益を得ることはもうありません。 DTOは、内部ドメインモデルをバックエンド実装から分離し、それぞれが独自のペースで進化できるようにします。
- 単一の責任 のクリーンな設計原則と実際には整合していません
注意：ドメインモデルが単純な場合にのみ使用してください。 1つのオブジェクトが単純であるが、モデル全体がかなり複雑になるのは良い考えではありません。アクティブなレコードを作業単位、アイデンティティマップなどと組み合わせる必要がある場合、アクティブレコードは多くの問題を引き起こすためです パターンエンタープライズアプリケーションアーキテクチャの 。