Ideia de arquitetura
01/12/2015 08:25
1
Pessoal, estava divagando sobre uma arquitetura baseada em "plugins de negocio" e gostaria da opinião dos senhores
Imaginem que sua empresa mantém um sistema voltado a postos de combustível, outro para restaurantes e outro para empresas de beneficiamento de rochas ornamentais
São negócios completamente diferentes, com regras bem distintas, de modo que tentar comportar tudo num único projeto seria um pesadelo de manutenção. Contudo, também há muita coisa em comum: Todos possuem um fluxo de caixa e estoque, por exemplo, de forma que há muito código que pode ser aproveitado.
Imaginem então usar a arquitetura de plugins do Grails (Ou do Gradle, em se tratando de Grails 3.x) para cada aspecto do negocio.
Então você teria um plugin com todo o fluxo de caixa (domínios, serviços, controladores, views, etc), outro para o estoque, etc.
Um plugin "pdv" teria como dependencias o plugin de caixa e estoque de modo a comandar entradas e saídas de caixa e estoque conforme necessario e, por sua vez, dispararia eventos a cada transação que seriam consumidos por um plugin "paf-ecf" que trataria da integração com um "paf-ecf" homologado. Se você for atender a uma UF que use NFc-e ao invés de PAF, basta empacotar a aplicação com outro plugin.
Por cima de tudo você teria por exemplo o projeto "software de posto" que incluirá os plugins relevantes MAIS a implementação das rotinas específicas daquele negócio.
Há muitos anos tentei desenvolver um modelo assim nos meus tempos de Delphi mas foi um fracasso, mas também a plataforma não ajudava em nada rsrs
Imaginem que sua empresa mantém um sistema voltado a postos de combustível, outro para restaurantes e outro para empresas de beneficiamento de rochas ornamentais
São negócios completamente diferentes, com regras bem distintas, de modo que tentar comportar tudo num único projeto seria um pesadelo de manutenção. Contudo, também há muita coisa em comum: Todos possuem um fluxo de caixa e estoque, por exemplo, de forma que há muito código que pode ser aproveitado.
Imaginem então usar a arquitetura de plugins do Grails (Ou do Gradle, em se tratando de Grails 3.x) para cada aspecto do negocio.
Então você teria um plugin com todo o fluxo de caixa (domínios, serviços, controladores, views, etc), outro para o estoque, etc.
Um plugin "pdv" teria como dependencias o plugin de caixa e estoque de modo a comandar entradas e saídas de caixa e estoque conforme necessario e, por sua vez, dispararia eventos a cada transação que seriam consumidos por um plugin "paf-ecf" que trataria da integração com um "paf-ecf" homologado. Se você for atender a uma UF que use NFc-e ao invés de PAF, basta empacotar a aplicação com outro plugin.
Por cima de tudo você teria por exemplo o projeto "software de posto" que incluirá os plugins relevantes MAIS a implementação das rotinas específicas daquele negócio.
Há muitos anos tentei desenvolver um modelo assim nos meus tempos de Delphi mas foi um fracasso, mas também a plataforma não ajudava em nada rsrs
0
Fala Magno Machado Paulo blz tem um software em java que tem uma arquitetura de plugins bem semelhante ao que vc quer é o sistema de portais corporativos liferay e em sua versão atual funciona bem, tenho um experiencia de pouco mas de 1 ano com liferay e ainda não tive problemas em aumentar suas funcionalidades por meio de plugins
01/12/2015 10:07
0
Oi Magno,
esta arquiteura que você propôs é muito comum: alguns clientes meus possuem exatamente isto. Diversas funcionalidades do negócio implementadas como plug-ins do Grails e que são reaproveitados em tempo de compilação.
Funciona muito bem desde que (e somente se) você tenha uma política de gestão de configuração e mudança *muito* bem organizada. Tenho clientes que implementam ERPs em Grails assim, por exemplo.
O grande problema, no final das contas, é a modularização. Neste sentido, a tecnologia que mais abriu minha cabeça sobre o assunto foi OSGi. Ela te disciplina a pensar componentes de uma forma mais rígida, e ainda te possibilita algo que considero fenomenal: a possibilidade de trocar componentes em tempo de execução, e não apenas compilação, como ocorre com os plug-ins do Grails.
A próxima iteração do motor deste site será baseado em uma plataforma de plug-ins que estou planejando parecida com isto.
Outro modelo bacana que dá pra tirar muitas ideias é o Wordpress: o modelo deles envolvendo plug-ins é muito interessante.
esta arquiteura que você propôs é muito comum: alguns clientes meus possuem exatamente isto. Diversas funcionalidades do negócio implementadas como plug-ins do Grails e que são reaproveitados em tempo de compilação.
Funciona muito bem desde que (e somente se) você tenha uma política de gestão de configuração e mudança *muito* bem organizada. Tenho clientes que implementam ERPs em Grails assim, por exemplo.
O grande problema, no final das contas, é a modularização. Neste sentido, a tecnologia que mais abriu minha cabeça sobre o assunto foi OSGi. Ela te disciplina a pensar componentes de uma forma mais rígida, e ainda te possibilita algo que considero fenomenal: a possibilidade de trocar componentes em tempo de execução, e não apenas compilação, como ocorre com os plug-ins do Grails.
A próxima iteração do motor deste site será baseado em uma plataforma de plug-ins que estou planejando parecida com isto.
Outro modelo bacana que dá pra tirar muitas ideias é o Wordpress: o modelo deles envolvendo plug-ins é muito interessante.
01/12/2015 14:29
0
Kico,
No caso dos seus clientes dividem apenas por uma questão de organização do projeto, ou realmente reutilizam os diversos módulos em dois ou mais sistemas diferentes?
No caso dos seus clientes dividem apenas por uma questão de organização do projeto, ou realmente reutilizam os diversos módulos em dois ou mais sistemas diferentes?
01/12/2015 14:43
0
Oi Magno,
reaproveitamento total: vejo os mesmos módulos serem usados em dois, três, quatro, infinitos projetos.
Funciona muito bem.
Inclusive, visto que você pode executar o comando "run-app" em um plug-in como se fosse uma aplicação normal, é possível ter um time dedicado ao desenvolvimento daquele plug-in como se fosse uma aplicação Grails normal, o que já vi ocorrer também.
reaproveitamento total: vejo os mesmos módulos serem usados em dois, três, quatro, infinitos projetos.
Funciona muito bem.
Inclusive, visto que você pode executar o comando "run-app" em um plug-in como se fosse uma aplicação normal, é possível ter um time dedicado ao desenvolvimento daquele plug-in como se fosse uma aplicação Grails normal, o que já vi ocorrer também.
01/12/2015 17:06
1
Ola Magno
Todos os nossos projetos aqui do banco que eu trabalho são modularizados exatamente da forma que vc falou. Todos são baseados na filosofia conhecida com DDD e principalmente no conceito de camada anti-corrupção para isolar os módulos. Quando vc modulariza, vc pode usar diferentes ferramentas para fazer o composição (wireling), vc pode usar OSGi, Gradle, Maven ou até jar'zinhos separados simples....
A solução fica fantastica, 100% reutilizavel, "mockavel", manutenivel e flexivel.
A partir de 2016 estaremos entrando na onda do microservice e cada modulo desse terra o sua IRL e serviço para facilitar ainda mais a publicação e manutenção dos mesmos.
Abraços...
Todos os nossos projetos aqui do banco que eu trabalho são modularizados exatamente da forma que vc falou. Todos são baseados na filosofia conhecida com DDD e principalmente no conceito de camada anti-corrupção para isolar os módulos. Quando vc modulariza, vc pode usar diferentes ferramentas para fazer o composição (wireling), vc pode usar OSGi, Gradle, Maven ou até jar'zinhos separados simples....
A solução fica fantastica, 100% reutilizavel, "mockavel", manutenivel e flexivel.
A partir de 2016 estaremos entrando na onda do microservice e cada modulo desse terra o sua IRL e serviço para facilitar ainda mais a publicação e manutenção dos mesmos.
Abraços...
01/12/2015 17:23
1
Kico,
Sobre OSGi você teria algum exemplo, algo que pudesse passar pra gente como ficaria em Grails? Eu pesquisei um tempo atrás mais não consegui executar com Grails.
Sobre OSGi você teria algum exemplo, algo que pudesse passar pra gente como ficaria em Grails? Eu pesquisei um tempo atrás mais não consegui executar com Grails.
02/12/2015 16:27
0
Oi Leandro,
minha maior frustração com Grails 2.0 foi que ele teria o mecanismo de plug-ins baseado em OSGi e na última hora cortaram fora. :(
Basicamente, trabalhar com OSGi em Grails é quase que igual ao que você faria usando o Java: é possível lidar com OSGi tanto embarcado quanto dentro de um container externo como, por exemplo, o Karaf e o Felix.
Como é algo que vou voltar a pesquisar *a fundo* agora, vou compartilhar aqui alguns links com você:
Como criar bundles Groovy com Gradle: http://hamletdarcy.blogspot.com.br/2009/08/groovy-osgi-gradle-makes-it-easy.html
Groovy & Grails on OSGi - http://blog.jetztgrad.net/grails-on-osgi/ (sequência de artigos muito interessante)
No geral, tem um livro sobre OSGi muito bom e gratuito. Se chama "OSGi in Practice", você pode baixá-lo neste link: http://njbartlett.name/files/osgibook_preview_20091217.pdf
É uma leitura fascinante, pois nos faz pensar bastante sobre o modelo de componentização e, mesmo que você não chegue a usar OSGi, abre a cabeça pra muitas possibilidades interessantes.
minha maior frustração com Grails 2.0 foi que ele teria o mecanismo de plug-ins baseado em OSGi e na última hora cortaram fora. :(
Basicamente, trabalhar com OSGi em Grails é quase que igual ao que você faria usando o Java: é possível lidar com OSGi tanto embarcado quanto dentro de um container externo como, por exemplo, o Karaf e o Felix.
Como é algo que vou voltar a pesquisar *a fundo* agora, vou compartilhar aqui alguns links com você:
Como criar bundles Groovy com Gradle: http://hamletdarcy.blogspot.com.br/2009/08/groovy-osgi-gradle-makes-it-easy.html
Groovy & Grails on OSGi - http://blog.jetztgrad.net/grails-on-osgi/ (sequência de artigos muito interessante)
No geral, tem um livro sobre OSGi muito bom e gratuito. Se chama "OSGi in Practice", você pode baixá-lo neste link: http://njbartlett.name/files/osgibook_preview_20091217.pdf
É uma leitura fascinante, pois nos faz pensar bastante sobre o modelo de componentização e, mesmo que você não chegue a usar OSGi, abre a cabeça pra muitas possibilidades interessantes.
02/12/2015 16:45
Ainda não faz parte da comunidade???
Para se registrar, clique aqui.
Aprenda Groovy e Grails com a Formação itexto!
Newsletter Semana Groovy
Os melhores blogs de TI (e em português) em um único lugar!
