I am beginning with Grails, read 2 books about it and am planning to read yours as soon as I can. One of my concerns is the lack of Grails best practices; does your book cover this subject? If not, can you point us to some resources?
One might argue that the best practices are the ones that work best for you and your projects / users / environment, etc.
That said, the practices that make sense in most other web development environments also apply to Grails, so I don't know of a body of thought on practices specific to Grails.
There are a couple of issues that we could discuss though:
Grails had not done much to encourage the use of packages for domain classes, controllers, etc. Many people giving demos of Grails also didn't use packages since it's quicker and demos are supposed to be short, right? Anyhow, some people took all this together to mean that Grails discouraged the use of packages, which it didn't. So, in the upcoming Grails 1.2, you will get a warning if you try to create a class, using the Grails scripts, if you don't use a package.
Then there's the issue of anemic domain models. http://martinfowler.com/bliki/AnemicDomainModel.html Some think that Grails encourages this practice too. I would say that Grails is pretty neutral about it. But whether the anemic domain model is a pattern or an anti-pattern is a subject that many are still debating. I could tell you my preference but that would have nothing to do with the topic of this forum. If you're interested you can email me at firstname.lastname@example.org.
I apologize if I appear to be skirting around your question. It's only because I am.
I agree with Martin Fowler's view that the anemic domain model is an anti-pattern. I don't feel quite as strongly about it as he does, but I do think that we miss out on much of the value of working with an object oriented language if we allow our domain classes to become just glorified record structures.
I used to think that Grails encouraged this sort of design but I think it's just what we see in demos. I think it might be a side-effect of the DTO pattern. Since we are often forced to move data from domain objects into value objects (basically records) in order to send them across the wire, I think developers begin questioning the value of duplicating everything. So, why not just have our domain classes be DTOs? Then we can put all our logic in a service layer.
This can work and if done carefully isn't a tragedy. Which is why I don't feel as strongly about it as some. However, I think we are more likely to end up with a mess using this style. I've seen many examples (some of them my own) of code that is checking the type of an object before doing something to it inside of a service method. (Here I will get a bit dogmatic) That's evil! If some bit of processing needs to be different based on what object is being acted on, that logic is screaming to become a method of that object or a related one.
My general rule is to put logic as close as possible to the data that it acts on or involves. I don't hold to that rule to the point of paralysis, but I try to do that first. If I can't find a good fit then I will look at moving the logic to a service class or helper class, etc. I am convinced that this principle helps me to end up with better designs.
There's my opinion. I would love to see / hear others.