Módulos e Pacotes

Virtual Machine Man Membro desde: 20/05/2009 11:21:32 Mensagens: 876 Offline

sergiotaborda wrote:

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.

Voce tem código algum código sem funcionalidade na sua aplicacao?

JavaEvangelist Membro desde: 26/02/2007 09:31:49 Mensagens: 323 Offline

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.

rodrigoy wrote: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.

É 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.

This message was edited 2 times. Last update was at 17/11/2009 09:15:49

"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.

A.L wrote:"Um módulo tem que ser identificável por si só."

Mas isso assume que eles são independentes? ...

O que quis dizer com "Um módulo tem que ser identificável por si só." é que o mesmo tem que ter sentido próprio, ser definível, ser completo para aquilo que propõe fazer, mesmo que dependa de alguma informação de outro módulo.

Essa definição de "identificável por si só" e "independencia" no que quis dizer, não se cruzam.

Uma pergunta de check list para definição de módulo seria:
Estou com dúvida para dar um nome ao meu módulo? Se sim, com certeza o escopo do seu módulo não esta bem definido.

maurenginaldo wrote:

A.L wrote:"Um módulo tem que ser identificável por si só."

Mas isso assume que eles são independentes? ...

O que quis dizer com "Um módulo tem que ser identificável por si só." é que o mesmo tem que ter sentido próprio, ser definível, ser completo para aquilo que propõe fazer, mesmo que dependa de alguma informação de outro módulo.

Essa definição de "identificável por si só" e "independencia" no que quis dizer, não se cruzam.

Uma pergunta de check list para definição de módulo seria:
Estou com dúvida para dar um nome ao meu módulo? Se sim, com certeza o escopo do seu módulo não esta bem definido.

Concordo contigo, eu me precipitei na interpretação, boas palavras

rodrigoy wrote: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!

Sim. Modules (Also known as Packages)

Acredito que a melhor forma é "Package by feature, not layer"

Joel... não é tão simples assim na minha opinião. Note que o conceito de Package pode mudar dependendo da linguagem (como explicado no próprio livro). Alí ele não está se referindo simplesmente a packages do próprio Java.

A.L wrote:"Um módulo tem que ser identificável por si só."

Vejo que isso é a relação com a Ubitiquous Language e não com analisar dependências...

This message was edited 1 time. Last update was at 19/11/2009 13:36:27

Na Siemens, tive a oportunidade de dividir o sistema em diversos módulos, cada um com seu próprio conjunto de pacotes. Portanto, existia uma diferença próxima da que o Sergio falou, mas não do ponto de vista comercial, mas puramente organizacional.

Tinhamos módulos para servidores DHCP, TCP, UDP, módulos para auxilio em interface gráfica, módulos para manipular som, telefonia, etc... Cada módulo poderia, se quisessemos, ser facilmente separado num .jar próprio (e, na verdade, muitas vezes fazíamos isso).

Quanto aos façades. Certamente existem façades entre os módulos, mas não me preocupava em fazer desse façade também um mediator. Muita gente encara o façade como um único, grande e inchado objeto que controla todo o módulo, e eu discordo radicalmente dessa abordagem.

Tinhamos um conjunto de classes coesas, que se comunicavam com o mundo externo através de interfaces bem definidas, mecanismos de eventos, etc. Como uma API qualquer.

Virtual Machine Man Membro desde: 02/06/2005 16:28:38 Mensagens: 702 Offline

andre_salvati wrote: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?

Interessante...

estou começando a procurar uma solução que me permita maior modularização e separação de responsabilidades no meu projeto e encontrei o SpringSource dm Server.

www.springsource.com wrote:
SpringSource dm Server? is a completely modular, OSGi-based Java server designed to run enterprise Java applications and Spring-powered applications with a new degree of flexibility and reliability. The SpringSource dm Server is based on the new SpringSource Dynamic Module Kernel? (dm Kernel).

Estou começando a achar que essa aversão da SpringSource aos padrões Java EE e que a sua participação intensa da definição dos padrões OSGI pode ser interessante para quem trabalha com grandes projetos, para quem quer aplicar métodos ágeis e para quem procura desenvolvimento de sistemas mais modulares.

Alguém usa o SpringSource dm Server?

Notícias, artigos e o maior fórum brasileiro sobre Java