Dicas de Arquitetura de Software com Java

org-320%2fschool-320%2f7d9bfc5e9dc56593d4a38668fdf743e1%2farquiteto2No curso AQT  M1 – Arquitetura de Software com Java, nós ajudamos os desenvolvedores Java a subir um pouco mais o nível de seus conhecimentos, deixando de ser meros programadores e passando a ter uma visão de arquiteto de software, compreendendo questões e princípios básicos de arquitetura. No final do curso, nós implementamos uma solução completa em java, desde de interfaces gráficas desktop , web, regras de negócio, até a persistência em banco de dados relacionais, provando então todos esses conceitos na prática.

Dezenas de alunos e profissionais tem feito o curso e além do feedback 100% positivo, eles tem me perguntando “como” poderiam evoluir a proposta arquitetural ministrado no curso, para um nível mais sofisticado e mais profissional. Hoje eu gostaria abrir essa conversa e dar cinco dicas sobre isso, a como adicionar mais produtos e melhorar a arquitetura proposta:

1.Validação de Negócio

No curso, a validação de negócio ficou dentro da classe domínio Cliente [domain model pattern], implementada de forma manual. Uma sofisticação dessa opção seria substituir a validação manual pela especificação java bean validation, evitando assim DRY e tendo uma melhor produtividade na validação. Sugiro provedor hibernate validation.

2.Fabricas

No curso, a criação do objeto responsável pela implementação da persistência seguindo o contrato da camada repositório [domain model repository pattern] ClienteJdbcImp, foi a classe FabricaPersistencia [Factory method pattern] implementada de forma manual. Uma sofisticação dessa opção seria substituir a fabrica manual pela injeção de dependência de uma especificação de um container IoC, evitando DRY e uma melhor produtividade. Sugiro provedor Spring IoC.

3.Persistência JDBC

No curso, o framework adotando como tecnologia de persistência da camada repositório foi o JDBC. Uma sofisticação dessa opção seria substituir o JDBC pelo JPA, evitando implementação improdutiva e burocrática das API de baixo nível, seus DRY e uma melhor produtividade. Sugiro provedor hibernate JPA.

4.Comandos SQL

No curso, os comandos SQL’s foram colocados dentro de atributos estáticos finais no formato string na classe ClienteJdbcImp. Uma sofisticação dessa opção seria não fazer SQL, deixando JPA gerar todos essas instruções dinamicamente via estratégia de ORM, evitando DRY e uma melhor produtividade. Sugiro provedor hibernate JPA.

5.Transação JDBC

No curso, os controle transacional ficou a a cargo JDBC usado de forma automática via connection=autocommit na classe ClienteJdbcImp. Uma sofisticação dessa opção seria usar controle de transações declarativas por AOP, evitando DRY, uma melhor produtividade e consistência. Sugiro Spring transactions.

6.DataSource

No curso, a abertura das conexões com o banco de dados é manual e no formato singleton. Uma sofisticação dessa opção seria não fazer o uso de DataSource, deixando um provedor de pooling de objetos fazer a gestão das conexões de forma escalável. Sugiro provedor commons DBCP. Para os interessados, temos o curso de JEE DataSource.

Conclusão

Como pode ser visto, seria impossível e impraticável ensinar cada um desses produtos/tecnologias nesse mesmo curso, ficando ai de sugestão para você, aluno do nosso curso estudar e avançar gradualmente em cada um desses tópicos, a medida que você se despertar para eles. Eu me coloco a total disposição para ajudar sobre o assunto. Até a próxima 🙂 !

“Portanto, não percam a coragem, pois ela traz uma grande recompensa. Vocês precisam ter paciência para poder fazer a vontade de Deus e receber o que ele promete.” Hebreus 10:35-36

Anúncios