Oi Pedro,

uma boa solução (e nada gambi!) é a criação de plugins para estas funcionalidades. Como você vai organizar a sua estrutura de plugins, ai é outra história.

Hà casos em que você vai querer modularizar apenas as classes de domínio e serviço pra poder criar interfaces customizadas para seus clientes. Em outros você pode até mesmo incluir a interface gráfica junto e modularizar o CSS. Vai depender muito da maneira como sua empresa organiza o seu código.

Outra solução interessante, talvez mais trabalhosa, seja você implementar sua lógica de negócio como arquivos jar separados que você simplesmente importa na sua biblioteca. Já fiz isto uma vez, mas não foi uma boa solução a longo prazo (acabamos percebendo que a modularização foi prévia demais).

Outra alternativa que eu acho muito interessante, mas cujo custo inicial é muito caro é você trabalhar com uma arquitetura OSGi, na qual cada módulo do sistema é um bundle. Mas novamente, é uma opção difícil de trabalhar inicialmente apesar de te oferecer ganhos espetaculares a médio e longo prazo.

Este post vai dar uma excelente discussão, razão pela qual o divulguei no Twitter do Grails Brasil. Valeu pelo tópico!

Demos inicio á "pluginzacao" de várias coisas que tinhamos, e foi dessa maneira mesmo: faziamos um projeto-plugin e depois instalavamos em quem usava.

Isso foi muito bom, pois nossas classes estavam ficando com responsabilidade bem alta sem muito sentido. Conforme fomos separando as classes diminuimos muito o que estava engessado.

Existe um "Projeto Principal", que tem varios plugins. Os plugins tem Models, e os Models do projeto principal agregam os Models dos plugins.
Exemplo:
tem um plugin que tem o User, que contem as informaçoes do usuario
e o plugin Transactions que tem as informaçoes de transacoes financeiras
no projeto principal tem um model Profile, que contém o User e Transactions

O springsecurity ficou na aplicação principal, por causa dos parametros de configuração.

Não sei bem se encaixa no tópico, mas uma maneira bem bacana de modularizar sistemas é usando SaaS (software as service).
Estou fazendo esse curso do coursera: https://www.coursera.org/course/saas
E não teve como não mencionar aqui, estou curtindo mto e recomendo =)

Consiste da idéia de disponibilizar sua aplicação como serviço (via get, webservice, etc)

Essa idéia ta crescendo bastante por causa do cloud, da facilidade de escalonar coisas, poder comunicar com aplicações em diferentes linguagens e reutilização.

Obrigado a todos, Henrique eu falei da "Gambi" rs no sentido de se eu quiser o que é um plugin como aplicação isolada sem a app principal, criar uma aplicação vazia apenas para abrigar este plugin me parece uma Gambi :-).

Mas bem, gostei aí das dicas, e acho que vou rumar para esta estrutura sugerida, eu nunca usei OSGi, ouço falar muito sobre isso, porém tenho medo de iniciar algo que eu não dê conta de concluir e onerar muito tempo do projeto, alguém tem experiência com isso no Grails aqui no fórum? Henrique ? Mussatto ?

Fui falar de SaaS, acabei falando de SOA hehe

Nunca trabalhei com OSGi =/

Mas a forma de modularizar que eu mencionei era disponibilizando os serviços via webservices soap / rest, e a comunicacao fica toda via xml ou json.

É bem chato pq tem esse trabalho de ficar parseando, mas por sorte o groovy tem uma magavilha chamada XmlSlurper:
http://groovy.codehaus.org/Reading+XML+using+Groovy%27s+XmlSlurper

Uma coisa já adianto, isso dá um trabalho sim, principalmente pra debugar.
Aí tem que ver se vale a pena

Lembrando que dá pra transformar os objetos em xml com o comando "as XML" tbm

Sim isso eu já uso muito

'render as XML'
e
'render as JSON'

sim sim, mas é bom mencionar pra ficar de referencia
tem mta gente que só le, fica com dúvida mas nao posta =)

Algumas praticas que ja vi fazendo eh criar um DTO pra mapear as entradas / saidas dos serviços e umas classes helper pra parsear os DTOs e criar os models

Só toma cuidado, por que modularizar com o intuito de reutilizar funcionalidades e código costuma ser um doloroso tiro no pé.

Quando você modulariza requisitos não funcionais ou de infraestrutura como ORM, envio de e-mail em massa, conversões, envio de nota fiscal eletronica, etc, é uma coisa que já é complexa. Mas você modularizar requisitos funcionais, que tem regras de negócio específicas de um cliente ou de um sistema, o negócio muda de figura.

Por exemplo, se você fez esse módulo financeiro pra um sistema que atenda uma loja de roupas, dificilmente ele vai ter os mesmos requisitos que um sistema que atenda uma empresa de logística.

Se você desenvolve um produto fechado, e quer fazer uma outra linha de produtos fechado, é mais fácil de fazer, já que você tem controle sobre as funcionalidade. Mas se você presta serviço de desenvolvimento pra várias empresas e quer reaproveitar entre esses vários projetos, simplesmente esqueça essa idéia.

IMHO...

Não, a ideia é na linha do que o Mussatto falou mesmo, a questão do Financeiro foi apenas um exemplo, outra coisa que pensei é no caso até de distribuição também, poder modularizar para poder distribuir, e para poder re-aproveitar também.

Mussato,

você possui algum manual mais descritivo sobre "pluginzacao" (Como gerar, manter e distribuir) com boas práticas e mais detalhado? Achei a documentação do Grails muito resumido sobre o tópico.

Ivgsilva,

Na minha opinião não tem uma prática definida =/
Modularização é uma coisa arquitetural e muda de pessoa pra pessoa, e de projeto pra projeto.

Quando fomos criar plugins no Grails, pensamos como se estivessemos criando bibliotecas do java (só que com varias coisas a mais), que tem que um conjunto de responsabilidades e isoladas. Quanto mais responsabilidade vc define pra uma classe / serviço, mais amarradas as coisas ficam.

Manual eu não sei dizer, mas posso apontar dois livros muito bons pra esse assunto: Clean Code e Pragmatic Programmer.
O Clean Code eu considero leitura obrigatoria =)

O maven foi fundamental pra criar os plugins.
A automatizacao dos testes e controle de versão foram um divisor de aguas.

Não lembro bem porque mas o Ivy deu muita dor de cabeça por não trocar as versões do plugin direito.

Seguimos esse tutorial: http://www.znetdevelopment.com/blogs/2012/07/15/grails-2-1-and-maven-integration-multi-module-projects/
Pra criar a estrutura do projeto.

Tem uma coisa que deu dor de cabeça aqui: quando vc cria um plugin (grails create-plugin), ele não vem por padrão com o plugin do hibernate pra usar direito os models

Desculpas por "em partes", é que fui lembrando das coisas.

Mussatto,

valeu pela dica e pelo tutorial. E o que vc fez para corrigir a falha da ausência do plugin hibernate (no grails create-plugin), instalou outro plugin complementar?

só mandei instalar o plugin do hibernate mesmo (e coloquei no pom.xml)