Desde o início de sua jornada como dev, você deve estar ciente dos problemas que um código sujo traz, não em um primeiro momento, mas sim algum tempo depois, com bug's aleatórios e a dificuldade na manutenção.
O mesmo problema ocorre com uma arquitetura de software mal planejada, onde no início tudo parece normal e não ha impacto na produtividade, porém depois de alguns anos o código fica complexo, todo o acoplamento criado não permite os times serem ágeis e entregar funcionalidades em um tempo satisfatório, e quando adicionado uma feature na "região norte" do sistema o "região sul" é impactada e tal problema só é descoberto em produção, então é proposto criar todo o sistema do zero, e a cada 5/7 anos esse ciclo vai se repetir, e a verdadeira raiz do problema, a arquitetura ruim, nunca é considerada.
Fazendo uma analogia entre a construção de um software e a de uma casa, imagine todo o processo de desenvolvimento da residência, desde o projeto até a entrega das chaves. Ao projetar e construir uma casa, bons arquitetos e engenheiros devem confluir suas ideias, sempre respeitando regras específicas, para que, após a entrega do imóvel, qualquer tipo de alteração possa ser realizada da maneira mais prática possível.
Imagine que algum tempo depois do imóvel pronto, o proprietário resolve fazer alguma alteração física da residência, como, por exemplo, ampliar um quarto, acrescentar um novo banheiro e fazer uma nova janela. Dependendo de como a casa foi concebida na mesa do arquiteto, uma alteração pode se tornar mais dispendiosa, demorar mais tempo para ser concluída, ou até mesmo impossível.
Assim como o planejamento de uma casa deve ser responsável e seu produto final precisa ter flexibilidade para alterações ou ampliações, a criação de um software também deve favorecer a qualidade do código. Vale lembrar ainda que, assim como um arquiteto de uma casa, o desenvolvedor do programa é o responsável pela entrega do produto e provavelmente em possíveis upgrades futuros.
Estabelecer uma arquitetura limpa pode facilitar seu próprio trabalho a médio ou longo prazo.
Para mais sobre Arquitetura Limpa.
Durante as últimas décadas, viu-se a evolução de um apanhado de ideias importantes sobre Arquitetura de Software, incluindo: a Arquitetura Hexagonal (também conhecida como Ports and Adapters) de Alistair Cockburn, DCI de James Coplien e Trygve Reenskaug, BCE de Ivar Jacobson, entre outros.(TheWiseDev)
Durante as últimas décadas, viu-se a evolução de um apanhado de ideias importantes sobre Arquitetura de Software, incluindo: a Arquitetura Hexagonal (também conhecida como Ports and Adapters) de Alistair Cockburn, DCI de James Coplien e Trygve Reenskaug, BCE de Ivar Jacobson, entre outros.(TheWiseDev)
Quarkus é um framework Java nativo em Kubernetes e de stack completo que foi desenvolvido para máquinas virtuais Java (JVMs) e compilação nativa. Ele otimiza essa linguagem especificamente para containers, fazendo com que essa tecnologia seja uma plataforma eficaz para ambientes serverless, de nuvem e Kubernetes.
Benefícios do framework:
- Criado por dev's para dev's
- Soporte a GraalVM
- Container First
- Possibilidade de desenvolver com código imperativo e reativo
Se você deseja saber mais sobre Quarkus, visite o site oficial deles: https://quarkus.io/ .
Consiste em uma API(CRUD de usuário) onde é possível passar no parâmetro da requisição qual implementação de banco de dados será utilizada, não parece algo muito corriqueiro, poderíamos ter uma lógica de negócio mais avançada aqui, porém foi implementado desta forma para facilitar a compreensão de uma das ideias principais por trás da arquitetura limpa, o alto nível de desacoplamento.
Temos duas opções de implementação que podem ser passadas no header, POSTGRES, onde irá realizar a persistência no banco de dados relacional PostgreSQL, e a outra opção MONGO, onde será realizada a persistência no banco de dados NoSql MongoDB.
Seguindo a teoria neste repositório temos uma implementação com algumas pequenas alterações no modelo original.
Necessário executar o docker-compose localizado na raiz do projeto, ele irá subir os containers dos bancos de dados.
docker-compose up
Você pode executar sua aplicação em Dev Mode, este que habilita o hot reload, utilizando o comando:
./mvnw quarkus:devNOTA: Quarkus possui uma Dev UI, que está disponível somente em Dev Mode no caminho http://localhost:8080/q/dev/.
Para empacotar:
./mvnw packageIsso irá produzir o arquivo quarkus-run.jar no diretório target/quarkus-app/.
Isso não é um über-jar.
Caso você queira empacotar como über-jar, execute o comando a seguir:
./mvnw package -Dquarkus.package.type=uber-jarPara executar o .jar empacotado convencionalmente:
java -jar target/quarkus-app/quarkus-run.jarPara executar o .jar empacotado como über-jar:
java -jar target/*-runner.jarVocê pode empacotar uma imagem nativa com:
./mvnw package -PnativeCaso você não tenha a GraalVM instalada, você pode empacotar uma imagem nativa em um container:
./mvnw package -Pnative -Dquarkus.native.container-build=trueVocê pode executar sua imagem nativa com:
./target/quarkus-clean-arch-base-1.0.0-SNAPSHOT-runner
Caso você queira saber mais sobre como buildar imagens nativas, consulte: https://quarkus.io/guides/maven-tooling.