Olá Italo!

Realmente esta pergunta é muito difícil.
Eu tento evitar ao máximo deixar regras no Controller, mas as vezes é meio difícil fazer isso.

Por exemplos, vamos imaginar que eu tenha que passar um objeto Pessoa para um service para fazer determinada operação.

class Pessoa {
  String nome
  String sobreNome

  static constraints = {
    nome nullable: false, blank: false
    sobreNome nullable: false, blank: false
  }
}

Eu não acho que seja necessário passar para o service validar os atributos das pessoa sendo assim eu faço isso no controller

class PessoaController {
  def pessoaService

  def processar(Pessoa pessoa){
      if (!pessoa.validate()) {
        respond pessoa, view: "edit"
        return
      }
      pessoaService.processar(pessoa)
  }
}

Espero que consegui me explicar!

Ajudou sim Leandro! Eu também tenho esse hábito, proveniente de minha experiência com outros frameworks.

No seu exemplo, com um command object, acho até estranho não passar o objeto pessoa para o service, já que o próprio controller tem ele "acoplado". Em um código meu, fiz algo assim:

class PessoaController {
  def pessoaService

  def processar(Pessoa pessoa){
      if (!pessoa.validate()) {
        respond pessoa, view: "edit"
        return
      }
      pessoaService.processar(pessoa.properties) // <- passo o properties
  }
}

Passando o properties ao invés do objeto. Fiz, mas não achei elegante, pois perde todo o acesso à implementação da class Pessoa.

Ainda não olhei como é feita a "exposição" de serviços no grails(dar acesso ao service para outras aplicações como uma api), mas qual o impacto dessa abordagem caso eu queira expor o serviço para outras aplicações via http ou outro protocolo?

Olá Italo!

Se eu entendi, a sua dúvida é compartilhar a regra de negocio para uma integracao com outros aplicativos.

Isto no grails é feito através de rest, onde voce vai utilizar o mesmo controller geralmente.

Eu estou utilizando a versao 2.3.1, onde foi concebida uma mudança grande nos tratamentos dos controllers justamente para facilitar a integração rest.

foi introduzido o método respond

este método verifica o tipo de chamada e expoe pra voce os dados no formato desejado.
Para você entender melhor gere um scaffold na versão 2.3.1 (vou levar em consideração que você gerou um scaffold para o dominio Pessoa).
Quando voce acessar a url localhost:8080/teste/pessoa vai retornar a pagina do index.
Porém se voce acessar a url localhost:8080/teste/pessoa.json ira te retornar os dados no formato json.
Voce pode usar também localhost:8080/teste/pessoa.xml que irá te retornar os dados no formato xml.

Este conceito pode ser utilizado para qualquer método contido no scaffold

Hummm, eu tinha entendido que o que era exposto era o próprio service e não o controller. Então a lógica vai no Service para promover a reutilização de código, é isso?

ps: tinha visto o respond no seu primeiro exemplo. Estranhei mas não fui atrás. Obrigado pela explicação e link!

Exatamente os services são utilizados para reutilização, padronização e organização dos códigos e também tem os controles transacionais.

Este link tem uma explicação detalhada dos services

Valeu Leandro!

Vamos aos pontos.

Vamos supor que você possui a validação na sua classe de domínio (Domain), então a validação vai estar lá.
Colocar um monte de if's dentro da sua controller, já mostra que você está fazendo a coisa errada, você pode injetar uma classe de tratamento na sua controller mas não lhe dê mais atribuições do que ela precisa. A controller, faz apenas a manipulação do trafego de dados para uma lado (usuário final) e para o outro (DB, (java ~ groovy) class). Veja o Grails não é feito APENAS de Domain -> Controller -> Service. Essas possuem suas definições bem estabelecidas, mas você pode criar outras classes, Java ou Groovy, para fazer o correto tratamento deste caso.

Espero que tenha ajudado.