Durante a concepção de um novo software quase sempre nos deparamos com a mesma estrutura clássica de separação de camadas: dao, service, facade e controller.
Em aplicações corporativas, muitas vezes é interessante reutilizar códigos já usados em outras aplicações. Isso porque, nessas aplicações, geralmente as classes que compõem o modelo de dados são as mesma para a corporação.
O reuso de código é sempre mais eficaz quando temos uma camada de serviço fina, ou seja, com pouca lógica da aplicação em si. Porém, nos casos em que temos uma camada de serviço com muita lógica de negócio específica da aplicação, o reuso destes serviços para outras aplicações torna-se mais difícil.
Para melhor entender, veja considere a seguinte situação de exemplo:
Tem-se duas aplicações: uma de cadastro de funcionários e outra premiação de funcionários (aplicações típicas de empresas). Baseado nisso vamos considerar:
- As aplicações são distintas sendo que, cada uma delas tem a suas lógicas de negócio específicas (serviços);
- As aplicações pertencem à mesma corporação portanto,vamos considerar que o modelo de dados (model) e a camada de persistência (dao) são iguais para ambas;
- Cada aplicação tem sua fachada (facade) que expõe uma interface que controla o acesso dos diferentes clientes aos serviços.
Para maior compreensão veja a figura 1 com projeto das duas aplicações.
Figura 1
No exemplo mostrado pela figura 1, vimos que em algumas situações as aplicações podem requerer alguma lógica extra para que executem corretamente suas tarefas (métodos específicos da figura 1). Preferencialmente, os facades não devem conter lógicas de negócios e os services, idealmente, não devem conter lógicas específicas de um caso de uso ou aplicação. Desta maneira há mais reuso e o acoplamento entre os serviços diminui. Assim, pode-se introduzir uma camada que concentra a lógica específica e coordena ações dos services para que essa lógica específica seja corretamente executada. Esses serviços são chamados de application services.
Voltando ao exemplo, a organização dos serviços ficariam da seguinte forma (figura 2):
Figura 2
Ou seja, os métodos comuns mostrados na figura 1 ficariam dentro de FuncionarioService e os não comuns ficariam dentro FuncionarioAppService de cada aplicação.
Desta forma o facade de cada aplicação fica encarregado de fazer as devidas chamadas para a camada de negócio (figura 3).
Figura 3
Em síntese, isto é o que chama-se de componentização. No momento em que agrupamos coisas comuns e que podem ser reutilizadas em aplicações distintas, pode-se criar um JAR (componente) com esses fontes e usá-lo nas aplicações sem necessidade de replicação de código.
Até breve!
Postagens
