Amigos(as),
Vocês consideram módulos e pacotes/namespaces a mesma coisa? Como vocês modularizam a aplicação de vocês e o que buscam com isso? (estou escrevendo sobre isso e gostaria de avaliar a visão do mercado)
Abrações!
eu acho que módulos são partes do sistema, como um ERP tem a parte de finanças, estoque e outros
e pacotes eu considero com um agrupador de funcionalidades no sistema, como telas, entidades
quando vc diz modularizar, vc se refere aos pacotes em que as classes são divididas?? ou partes de um sistema??
bom em ambos eu busco agrupar funcionalidades
mas nos módulos eu coloco grupos de funcionalidades, como eu citei acima, como num ERP, a parte de gerenciamento de estoque
e nos pacotes eu coloco as coisas juntas, como por exemplo, as minhas exceções que eu faço, eu coloco em um pacote, as telas do sistema em outro, as classes que tem determinadas funcionalidades em outro
A minha definicao é parecida com a do zoren, talvez por ter trabalhado muito tempo com desktop, eu vejo modulo como um “executavel” independente, mas que compoe uma aplicacao maior. E pacotes seriam as separacoes logicas dentro de um modulo.
Nas aplicações de vocês os módulos se acessam livremente? Estoque precisa de informações de Faturamento, que precisa de informações de Vendas e assim por diante.
[quote=rodrigoy]Amigos(as),
Vocês consideram módulos e pacotes/namespaces a mesma coisa? Como vocês modularizam a aplicação de vocês e o que buscam com isso? (estou escrevendo sobre isso e gostaria de avaliar a visão do mercado)
[/quote]
Pacote é uma unidade de divisão que tem relação com a visibilidade das classes, seus métodos e atributos. É uma forma de organizar codigo, não funcionalidade.
Módulo é uma unidade de divisão comercial. O sistema é encarado e vendido como um conjunto de módulos. A comunicação entre eles é “segredo” do software. normalmente módulos podem ser adicionados/ativados por demanda do cliente sendo que mais módulos = mais caro. Isto não significa que o código não está já lá, significa que o usuário não tem acesso, mas muita gente acha que o código não pode estar lá por causa de segurança contra hacks. Isto é especialmente verdade quando os módulos são ativados por códigos de ativação.
Leia módulos aqui como Modules no contexto da DDD e não no contexto comercial/licença e etc…
(acho estranho aqui que qualquer discussão sobre repositórios traz um monte de gente, mas discussão sobre Modules e Aggregates da DDD - que são mais importantes - ninguém discute)
Um módulo pode acessar informações do outro. Mas se você for pensar em reuso, o maior desafio é deixar os módulos desacoplados pra você poder reutilizar um módulo independentemente dos outros.
[]'s
Rodrigo Auler
Um módulo pode acessar informações do outro. Mas se você for pensar em reuso, o maior desafio é deixar os módulos desacoplados pra você poder reutilizar um módulo independentemente dos outros.
[]'s
Rodrigo Auler
[/quote]
Concordo plenamente.
[quote=Rodrigo Carvalho Auler]Um módulo pode acessar informações do outro. Mas se você for pensar em reuso, o maior desafio é deixar os módulos desacoplados pra você poder reutilizar um módulo independentemente dos outros.
[/quote]
Imagine que um módulo pode ter umas 30 classes, e outro módulo tem também 30 classes. Essas classes podem enviar mensagens entre si livremente? Como vc desacopla hoje?
[quote=rodrigoy][quote=Rodrigo Carvalho Auler]Um módulo pode acessar informações do outro. Mas se você for pensar em reuso, o maior desafio é deixar os módulos desacoplados pra você poder reutilizar um módulo independentemente dos outros.
[/quote]
Imagine que um módulo pode ter umas 30 classes, e outro módulo tem também 30 classes. Essas classes podem enviar mensagens entre si livremente? Como vc desacopla hoje?[/quote]
Acho que se elas enviam mensagens livremente entre si deveriam estar num mesmo package, eu procuro nao ter relacao bidirecional entre eles. Por exemplo, meu package contasreceber conhece e tem acesso livre as classes package vendas, mas o package vendas desconhece a existencia do contasreceber.
[quote=rodrigoy][quote=sergiotaborda]
…
[/quote]
Leia módulos aqui como Modules no contexto da DDD e não no contexto comercial/licença e etc…
(acho estranho aqui que qualquer discussão sobre repositórios traz um monte de gente, mas discussão sobre Modules e Aggregates da DDD - que são mais importantes - ninguém discute)[/quote]
Porque Repositorio é um design pattern pre-DDD que tem significado por si mesmo e utilidade por si mesmo e muita utilidade no cenário atual dominado pelo Hibernate ( DomainStore).
Ou seja, é porque na realidade não estamos falando de DDD 
Pra ser bem sincero, mesmo tomando todos os cuidados, é muito difícil deixar o módulo realmente reutilizável. Acho que isso só funciona se você tem um produto
e vender o mesmo produto em pedaços. Mas se você faz software sob demanda, acho difícil reutilizar módulos inteiros em outro projeto sem ter que mexer neles. Eu diminuo ao máximo o acoplamento entre os módulos só pra deixa-los mais testáveis, mas não visando reutilização.
Qual a sua intenção? Qual o nível de reutilização que você procura? Reutilizar só negócio ou reutilizar UI tb?
[]'s
Rodrigo Auler
A algum tempo venho procurado uma solução para empacotar uma aplicação web em módulos funcionais.
Ex:
erp.ear
– contabil.war
– contabil.jar
– faturamento.war
– faturamento.jar
etc
Alguém chegou nesse nível?
Exatamente Rodrigo, separar módulos é para organizar, melhorar a visão, diminuir a complexidade, testar modularmente…
Vejo poucas pessoas fazendo isso, e vejo que o simples empacotamento de classes não colabora para os itens acima.
Vcs usam Façades para integração entre módulos?
De uma olhada no livro de DDD onde esse assunto é discuto a exaustao.
Voce tem código algum código sem funcionalidade na sua aplicacao? :shock:
Isso é um assunto tb que já vi vários arquitetos e projetistas tratarem de formas diferentes, mais o que mais vejo é a seguinte estrutura:
Módulos: Utilizando como agrupamento de funcionalidades como por exemplo (Financeiro (web, api, core, domain), estoque (web, api, core, domain), venda (web, api, core, domain));
Pacotes: Entram dentro dos módulos para separação de meio que responsabilidades tb, mais dentro do contexto global de um módulo exemplo (dentro do financeiro, teremos os pacotes de entidades, talvez criteria, utils, vo);
Vejo tb a divisão dos módulos pensando em camadas(Layers) por exemplo, WEB (Financeiro-web, Estoque-web, etc), CORE (Façades e services. Ex. Finaceiro-core), API (Interfaces de serviços. Ex. Financeiro-api etc), DOMAIN (Dominio da aplicação. Ex. Financeiro-domain, etc).
Vejo bastante isso integrado com o Maven por exemplo, e ai com relação a chamada indiscriminada de funcionalidade entre os módulos, causa por consequência dependência cíclica, fazendo com que os módulos tenham de ser bem estruturado e independentes, senão é uma boa idéia ver a possibilidade de unilos.
Já vi de várias formas, e nunca vi nenhum artigo técnico dizendo a melhor forma de se fazer isso mesmo, acho que parte mais da estratégia adotada pelo arquiteto ou projetista, ou seja lá quem for.
Até mais.
[quote=rodrigoy]Exatamente Rodrigo, separar módulos é para organizar, melhorar a visão, diminuir a complexidade, testar modularmente…
Vejo poucas pessoas fazendo isso, e vejo que o simples empacotamento de classes não colabora para os itens acima.
[/quote]
É muito do conceito explicado em Modules (A.K.A Packages) na DDD.
IMHO creio que Façades ou elementos de fronteiras acabam sendo necessários quando existe a necessidade dos módulos conversarem entre si. O nivel de acoplamento creio que seja inversamente proporcional a organizacao que esses modulos tem e quais responsabilidades seus elementos tem no contexto do projeto.
Em uma visão bem simplificada vejo que:
pacotes = organizar o código
modulos = agrupar funcionalidades
“Um módulo tem que ser identificável por si só.”
Tento sempre fazer módulos que sejam independentes, que não dependam de outros módulos, mas em um ERP dificilmente essa independencia chega a 100%. Não sei a opinião dos colegas. mas considero que existem “tipos” de módulos, onde alguns módulos funcionam independentes, tem sua aplicabilidade, mas servem de apoio para outros módulos. Vejam o exemplo.
Módulo de Cadastros Básicos (cidade, país, profissão, pessoa física, pessoa jurídica, estado, escolaridae, …)
- Módulo Relatórios Gerais (necessita do Cadastros Básicos)
- Módulo Compras (necessita do Cadastros Básicos)
O módulo de compras funciona sem o relatórios gerais e vice-versa, mas os dois “dependem” de pedir informações para o cadastros básicos.
“Um módulo tem que ser identificável por si só.”
Mas isso assume que eles são independentes? Seria uma regra? Igual voce disse, em certas situações é praticamente impossivel torna-los independentes, devia ter uma regra para ‘módulos correlacionados’ ou algo do tipo rsrs.