Estou naquela epoca do ano que fico querendo tatuar (de novo). Vi essas tatuagens de renda que sao tao bonitas, artisticas & sexy. Fica de inspiracao para quem tambem esta nessa mesma fase do ano! Quem nunca quis fazer um passeio de balao? Creio que poucas imagens nao mais ludicas, calmas e pacificadoras do que a de um balao e sua cestinha. Vao aqui varias imagens e ideias para quem tem vontade de marcar essas sensacoes na pele. Imagens daqui e daqui. Durante a concepcao de um novo software quase sempre nos deparamos com a mesma estrutura classica de separacao de camadas: dao, service, facade e controller.Em aplicacoes corporativas, muitas vezes e interessante reutilizar codigos ja usados em outras aplicacoes. Isso porque, nessas aplicacoes, geralmente as classes que compoem o modelo de dados sao as mesma para a corporacao.O reuso de codigo e sempre mais eficaz quando temos uma camada de servico fina, ou seja, com pouca logica da aplicacao em si. Porem, nos casos em que temos uma camada de servico com muita logica de negocio especifica da aplicacao, o reuso destes servicos para outras aplicacoes torna-se mais dificil.Para melhor entender, veja considere a seguinte situacao de exemplo:Tem-se duas aplicacoes: uma de cadastro de funcionarios e outra premiacao de funcionarios (aplicacoes tipicas de empresas). Baseado nisso vamos considerar:As aplicacoes sao distintas sendo que, cada uma delas tem a suas logicas de negocio especificas (servicos);As aplicacoes pertencem a mesma corporacao portanto,vamos considerar que o modelo de dados (model) e a camada de persistencia (dao) sao iguais para ambas;Cada aplicacao tem sua fachada (facade) que expoe uma interface que controla o acesso dos diferentes clientes aos servicos.Para maior compreensao veja a figura 1 com projeto das duas aplicacoes.Figura 1No exemplo mostrado pela figura 1, vimos que em algumas situacoes as aplicacoes podem requerer alguma logica extra para que executem corretamente suas tarefas (metodos especificos da figura 1). Preferencialmente, os facades nao devem conter logicas de negocios e os services, idealmente, nao devem conter logicas especificas de um caso de uso ou aplicacao. Desta maneira ha mais reuso e o acoplamento entre os servicos diminui. Assim, pode-se introduzir uma camada que concentra a logica especifica e coordena acoes dos services para que essa logica especifica seja corretamente executada. Esses servicos sao chamados de application services.Voltando ao exemplo, a organizacao dos servicos ficariam da seguinte forma (figura 2):Figura 2Ou seja, os metodos comuns mostrados na figura 1 ficariam dentro de FuncionarioService e os nao comuns ficariam dentro FuncionarioAppService de cada aplicacao.Desta forma o facade de cada aplicacao fica encarregado de fazer as devidas chamadas para a camada de negocio (figura 3).Figura 3Em sintese, isto e o que chama-se de componentizacao. No momento em que agrupamos coisas comuns e que podem ser reutilizadas em aplicacoes distintas, pode-se criar um JAR (componente) com esses fontes e usa-lo nas aplicacoes sem necessidade de replicacao de codigo.Ate breve! O post de hoje e uma critica a gerencia de projeto de software.Tenho visto ultimamente que muito se fala de processo, metodologia, cronograma e pouco se e falado de construcao de