Boa noite Savius.

O que você precisa fazer, basicamente, é a modelagem via Domain mesmo da sua regra de negócio. Sò assim você vai conseguir identificar ambiguidades, como você citou, e outros possíveis problemas.

Para te ajudar melhor, falo por mim, precisaria compreender um pouco mais da sua necessidade. Mas siga esta regra que citei acima. Não necessariamente uma Domain é um objeto de persistência, o Groovy apenas fornece algumas convenções (CoC) para classes que estão na pasta "domain", como save, update, addTo*, e por aí vai...

Vamos lá...

Um atributo que repete muito em tabelas diferentes e com a mesma finalidade, no processo de normalização de dados você vai se deparar com esta inconsistência. Neste seu caso, o ativo é para saber se a linha é ativa, imagino eu, e a descrição, seja uma breve descrição sobre o valor no banco. São itens necessariamente essenciais, crie uma Domain (X) com estes valores, e nas suas outras Domain, referência ela com o belongsTo (existem outras formas, mas com o mesmo objetivo final de fazer isso, olhe na documentação do GORM sobre relacionamentos). Problema resolvido.

Grande abs e boa sorte com o projeto.

Oi Carlos, obrigado pela atenção. Os campos são exatamente para esta finalidade: identificar a informação para o usuário e "deletar" o resgistro quando necessário. Seguindo sua sugestão seria isso:

class Generica {
String descricao
Boolean ativo
}

e nas demais

class Empregador {
belongsTo [generica : Generica]
}
?

De repente funciona. Aí se eventualmente o Empregador precisar de mais campos não afetaria nenhuma outra que esteja relacionada com a Generica. O pensamento é esse ?

Aí se eventualmente o Empregador precisar de mais campos não afetaria nenhuma outra que esteja relacionada com a Generica.

Não somente isso. Pense que amanhã você poderia querer retirar o campo descrição. Seria trabalhoso, pois teria que remover em todas as Domains este campo. Assim você evita este retrabalho. Não se esqueca que você pode trabalhar de forma mais OO ainda, usando inherits.

Não tem muito sentido Empregador (por exemplo) possuir atributos e métodos que não fazem parte da sua caracterísca como objeto. Afinal Domains são objetos, lembre-se disso, não meramente um espelho do seu banco! Crie suas Domains com características de Objeto mesmo. Deixe o GORM (Hibernate) fazer o seu trabalho, não o faça por ele (DRY).

Exempplo:

class Pessoa {
    String nome

    static constraints = { //do something... }
    static mapping = { //do something else...}
    
}

class Empregador extends Pessoa {
    static constraints = { //do something... }
    static mapping = { //do something else...}
}

Seu banco (resumidamente) ficaria assim:

+---------------+
| Field         |
+----------------
| id            |
| version       |
| nome		|
| class		|
| cargo		|
+---------------+

Nos dê o feedback do resultado depois.

Grande abs e boa sorte com o projeto.

Oi Carlos, também parto da premissa de que estou trabalhando com objetos. E não tenho o menor interesse de trabalhar no lugar do gorm (hehehe)

Fora isso, a idéia de trabalhar com herança não me empolga muito pois sei (experiencia própria) que não é tão simples como geralmente lemos nos livros. Estou mapeando outras classes (pq o sistema já está em produção (tá certo, fui obrigado pelos processos internos a fazer em jsf)) mas agora o sistema está tomando proporções mais administrativas e outros módulos estão previstos. Trabalho com grails desde 2010 e não ousaria compará-lo aqui. Hoje estou com mais autonomia junto a meus gestores para a tomada de decisões. Hoje existe no banco cada tabela (das entidades já citadas) com seus campos string e boolean. O que quero é redesenhar com um melhor design.

Mas fique certo que assim que esta parte estiver "no ponto" venho para postar a solução adotada e ouvir as opiniões.

Abraço.

Apenas para constar, não sou Xiita com tecnologia (a ponto de dizer: seria muito melhor com framework x... se fosse já teria terminado e blá blá...)

Mas quero "qualidade de vida". E apesar de todos os recursos (ou melhor, componentes visuais) que o primefaces oferece, está longe da simplicidade do grails.

Legal Savius.

Entendi a situação. Mas cara boa sorte com o projeto aí.

Grande abs. E qualquer perrengue pode postar por aqui, pois a comunidade está cada dia mais ativa!