私のドメインクラスのいくつかはかなり豊富になっています：それらは興味深い比較可能なものを実装し、プラス、マイナス、乗算、除算を持っているかもしれません、多くはサービスを呼び出して複雑なことを決定するいくつかの便利なゲッターを持っています。そして何よりも、それらは適切な特性を持っています。私はこれらを通常の「データベーストランザクション」と、これらすべてのメソッドを持つオブジェクトが必要なだけで保存したくない場合の両方に使用しています。
私のチームメートは、これは非常に悪いことだと確信しており、DTO（データ転送オブジェクト）を使用する必要があるとアドバイスしています。これは、私が理解しているように、ドメインクラスのコードのコピー/貼り付けを含むPOGO/POJOになります。本当に乾燥しておらず、メリットがわかりません。ドメインオブジェクトを通常のオブジェクトとして使用することに何か問題がありますか？DTOのポイントが欠けていますか？
アプリケーションのドメイン層は通常、永続クラスと非永続クラスで構成されているため、Grailsドメインクラスの名前は多少間違っています。ただし、Grailsドメインクラスは常に永続的です。非永続ドメイン（従来の意味で）クラスを持つことができますが、それらはsrc/groovyまたはsrc/javaにある必要があります。ドメイン層がアプリケーション内で2つの場所に分割されるため、これはイライラする可能性があります。のようなものなど、非永続的なドメインクラスのリクエストがありましたが、static persistent = falseまだ実装されていません。
ドメインクラスの非永続的な機能（検証、依存性注入など）を利用したい場合は、データベースでバックアップできるクラスがあれば問題ないと思いますが、そうではありません。それをコードに文書化するか、特別なパッケージ構造や命名規則などの何らかの規則を設定する必要があります。、、などsave()のGORMメソッドを呼び出さない場合、データベースへのアクセスはありません。list()findAllByFoo()
DTOに関する限り、DRYを解除することもできますが、役立つプラグインがあります。http：//grails.org/plugin/dtoを参照してください。しばらく更新されていませんが、まだ機能していると確信しています。構文を使用して永続ドメインクラスインスタンスからDTOインスタンスを作成する優れた機能がありますdomainObj as DTO。クラス間で変更を同期し続ける必要がありますが、最初のDTO生成はスクリプトを介して自動的に行われます。
私はあなたが正しい道を進んでいると思います。
1-ドメインクラスを処理するためだけにクラスを作成する必要がある瞬間に、モデルをより結合します。より多くの依存関係を作成していますが、これは明らかに悪いことです。オブジェクトは、自分自身の面倒を見ることができる必要があります。
2-友達が話しているモデルは、実際には貧血ドメインモデルとして知られています。このモデルでは、プログラムのロジックからデータが分離されており、MartinFowlerによってアンチパターンとして最初に記述されました。ロジックとデータのこの分離は、手続き型プログラミングでは非常に使用されますが、オブジェクト指向プログラミングでは使用されません（OOPの目的は正反対です）。
3-コードの再利用を減らします。
4-データから分離されたロジックを初期化する必要があると、テストが難しくなります。同時に、システムからデータが漏洩します。
確かに、DTOは使用できるものです。ただし、そうすることはお勧めしません。当初は、プロセスまたは層を介してデータ（オブジェクト）を伝送するように設計されていました。その後、何らかの理由で、人々はそれをレイヤー間で使用し始めましたが、これは価値がありません。プログラムをより複雑にし（これらのエンティティをアプリケーション全体に分散させると）、グローバルアクセスが可能になります。
あなたがしていることはリッチドメインモデルと呼ばれ、それを使用することに問題はありません。しかし、もちろん、それに注意する必要があります。クラスの責任が多すぎる場合は、役立つ別のクラスを設計するときが来たかもしれません（SRPの原則に違反している可能性があります）。
Grailsでドメインオブジェクトがどのように設計されているかを見てみましょう。豊富なモデル（検証、DBトランザクションなど）を作成することをお勧めします。