[quote=A.L]“Um módulo tem que ser identificável por si só.”
Mas isso assume que eles são independentes? …[/quote]
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.
[quote=maurenginaldo][quote=A.L]“Um módulo tem que ser identificável por si só.”
Mas isso assume que eles são independentes? …[/quote]
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.
[/quote]
Concordo contigo, eu me precipitei na interpretação, boas palavras
[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)
Abrações!
[/quote]
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.
Vejo que isso é a relação com a Ubitiquous Language e não com analisar dependências…
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.
[quote=andre_salvati]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?
[/quote]
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.
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?