Some of my domain classes are getting rather rich: They implement an interesting comparable, might have plus, minus, multiply and div, many have some convenient getters which call services and determine complicated things. And most of all, they have the right properties. I am using these both for the normal "database transactions" and also in times when I just want an object that has all those methods but may not want to save it.
My teammates are convinced that this is very bad, and advise that I should be using DTO (Data Transfer Objects) which, as I understand, would be a POGO/POJO with one of the domain class' code copy/pasted in. This seems really un-dry, and I can't see the benefit. Is there something wrong with using domain objects as regular objects from time to time? Am I missing the point of DTO's?
Grails domain classes are somewhat misnamed, since an application's domain tier is usually made up of persistent and non-persistent classes. But Grails domain classes are always persistent. You can have non-persistent domain (in the traditional sense) classes but they would have to be in src/groovy or src/java. That can be frustrating because then the domain tier is split in the application into two places. We've had requests for non-persistent domain classes, e.g. something like static persistent = false or something similar, but it's not implemented yet.
I think if you want to take advantage of the non-persistent features of domain classes (e.g. validation, dependency injection, etc.) then it's fine to have some classes that could be database-backed but aren't. You just need to document that in the code or have some sort of convention, e.g. a special package structure or naming convention. If you never call GORM methods like save(), list(), findAllByFoo(), etc. then there won't be any database access.
As far as DTOs go, they can be un-DRY but there's a plugin that helps - see http://grails.org/plugin/dto. It hasn't been updated in a while but I'm pretty sure it still works. It has a nice feature where it will create a DTO instance from a persistent domain class instance with the syntax domainObj as DTO. You do need to keep changes synced between the classes, but the initial DTO generation is automatic via a script.