Pesquisar na Comunidade

Olá pessoal faz algum tempo que não trago conteúdo, vou tentar estar levando essa aba da comunidade para realidade atual do ecossistema Java, hoje começaremos com o feijão com arroz que é o nosso clássico da engenharia de software a arquitetura de monolitos. Vies em Foco: Spring Framework (Spring Boot) Indice: O que é Como se arquiteta um monolito Sobre o banco de dados Versionamento de banco de dados Como subimos um monolito usando Java 1 - O QUE É : O monolito é uma arquitetura de software focada na centralização dos recursos, entretanto não significa que toda nossa arquitetura se limite a um monolito, esse conceito vem de um minério monolito ou seja uma pedra "grande" e sólida em um só local, ou seja imagine que temos um servidor onde tudo será acessado por ele, não significa que esse mesmo recurso não possa possuir "Jobs" (microsserviços) assincronos resolvendo seus problemas, mas sim que seus recursos estão centralizados. 1.1 = Exemplo de aplicação: Servidor Backend com CRUD(OPERAOES COMO INSERT, UPDATE E DELETE) de um PDV (ponto de venda) abre caixa, fecha vendas, lança notas, fecha caixa. O cliente pode ser anexado a esse servidor ou externo a esse servidor, assim centralizamos o recurso. 2 - Como se arquiteta um monolito: 2.1 VERSIONAMENTO - Um monolito deve ser organizado, avisando sempre o seu fluxo de versionamento, geralmente por padrão em empresas grandes utilizamos git ou svn, entretanto devido a grande facilidade git é quase sempre a melhor solução, assim decidindo nosso tipo de versionamento como por exemplo (TRUNK) onde possuimos apenas 1 branch (PROCURE SOBRE COMMIT FLOW), o commit é sempre feito de forma linear ou seja é feito 1 fetch (atualização do projeto) e logo após caso não haja merge conflict (junção de código) o commit é feito, do contrário é resolvido os problemas de merge e logo após é feito o commit e o push (envio para o repositório remoto). 2.2 PACOTES- Recentemente tenho realizado diversas conversas com um amigo próximo sobre a arquitetura de monolito modular, essa proposta visa organizar seus módulos e pacotes, visando o menor acoplamento de pacotes possível, assim separando as regras de infra estrutura, banco e tudo mais e diminuindo as execuções de métodos via HTTP (aumentando as chamadas locais), logo como possuimos nossos recursos organizados de seguinte forma: -> PACOTE 1 - 1 Classe (Service) de entrada de dados -> PACOTE 2 - 1 Classe (Service) de entrada de dados -> PACOTE 3- 1 Classe (Service) de entrada de dados 2.3 DEFINIÇÃO DE MODULOS - (module-info Java 9 feature): Aqui definiremos como cada pacote deve se relacionar, assim não tornando visíveis pacotes externos a nossa aplicação Oracle Java 9 features, por exemplo Exportamos pacote 1 para apenas o pacote 2, assim torna-se mais fácil e o menor o acoplamento entre os pacotes. 2.4 ORGANIZACAO - Em uma aplicação completa o sistema de pacotes seria feito da seguinte forma: -> MODEL - Classes que representam entidades do banco; -> REPOSITORIES - Interfaces que permitem a realização de consultas por meio de ORM (no meu caso é hibernate); -> CONTROLLERS - Serviços HTTP onde são disponibilizados recursos como por exemplo um GET /produtos (listagem de produtos); -> VIEW (caso seja utilizado views nesse mesmo projeto) - Ou seja suas páginas web ficaria aqui no padrão do java geralmente se utiliza web-inf como default ou se disponibiliza dentro de resources usando thymeleaf, hoje atualmente as aplicações web são desenvolvidas em linguagens diferentes, então eu recomendo fortemente que você utilize Java somente no Backend como é uma linguagem muito versátil e estrutura, com diversos recursos e muita solidez no mercado; -> Modules ( nossos pacotes irão aqui) -> Arquivo module-info (definições de modulos como expliquei anteriormente) 3. Banco de dados - Geralmente utilizamos Frameworks que abstraem a forma com a qual configuramos nosso projetos, em uma projeto Java sem Framework utilizamos o arquivo dataSource, adicionamos uma lib de qual banco realizamos a conexão e assim conseguimos realizar nossas queries de forma manual, entretanto atualmente praticamente todos utilizam Spring Framework ou Quarkus, onde conseguimos realizar facilmente nossa configuração de banco em arquivos como application.properties, adicionamos nossa lib ao nosso automatizador de compilação como por exemplo Maven ou Graddle, baixamos nossa dependencia, opcionalmente adicionamos um ORM como por exemplo Hibernate, assim conseguimos realizar queries de forma fácil, por exemplo: -> SQL: SELECT * FROM USUARIOS WHERE ID = 1 -> CONSULTA COM ORM: usuarioRepository.findById(1) -> Retorna um Optional<Usuario> O consumo dentro de um método seria algo como: CONTROLLER -> @RestController public class UsuarioController { private final UserService service; @Autowired public UsuarioController(UserService service) { this.service = service; } @GetMapping("/usuarios/{id}") public Usuario getUsuario(@PathVariable int id) { return service.getUsuario(id); } } SERVICE -> @Service public class UserService { private final UsuarioRepository usuarioRepository; @Autowired public UserService(UsuarioRepository usuarioRepository) { this.usuarioRepository = usuarioRepository; } public Usuario getUsuario(int id) { return usuarioRepository.findById(id) .orElseThrow(() -> new UsuarioNaoEncontradoException()); } } @Repository interface UsuarioRepository extends JpaRepository<Usuario, Long> { Usuario findById(long id); // Outros métodos personalizados do repositório, se necessário } 4 - Versionamento de banco de dados: Imagine que você tem um mini projeto ai na sua linguagem favorita, acredito que você ja acessou seu banco usando alguma ferramenta como por exemplo seu phpmyadmin ou navicat, muito bom correto, você consegue alterar coisas direto no banco, isso parece mágico, mas entretanto e como fica alterações de schema do banco ? você vai fazer backups regulares para salvar o schema ? bom esse é o jeito de como não fazer as coisas, mesmo um backup ou um sistema de raid isso não é uma solução que você deveria depender, bom no mundo real no Java utilizamos o sistema de migrations, assim como Laravel (PHP), entretanto utilizamos uma dependencia (LIB) chamada flyway, com ela é possível a cada deploy em produção o SCHEMA, seja atualizado e versionado de forma caso haja necessidade de rollback (VOLTAR AS ALTERAÇÕES) é possível e viável. 5 - Como subimos essa aplicação: Supondo que viemos do viés de construir apenas nosso Backend com Java, é super fácil subirmos essa aplicação, basta que adotemos um protocolo acessível como (HTTP), dessa forma podemos utilizar um JAR, como por exemplo no ecosistema Spring, buildamos nosso jar via maven ou graddle (com tomcat provided), e com esse cara podemos montar um container ( para rodar em DOCKER) ou até mesmo fazer o deploy diretamente em uma VM o jar e subir toda infraestrutura de forma manual e expor na internet (UM POUCO PERIGOSO SEM UM FIREWALL DECENTE, ISSO TAMBEM SE APLICA AO CONTAINER, FAVOR ESTUDAR PROCOLO HTTP, REDES e WAF APLICADAS AO DEPLOY). Pronto, você chegou até aqui, apesar de talvez estar um pouco perdido, você entendeu que existem coisas como arquitetura, pacotes, automatizadores de compilação como maven e graddle, padrão MVC, conceitos como services, containers, waf, frameworks, engenharia de software e por fim backend centralizado (com ou sem front) mais conhecido como monolito. PS: Não esse post não foi gerado pelo Chat GPT se tiver dúvida deixe abaixo. Gostou do conteúdo ? talvez você tenha interesse em projetos reais aplicados a problemas da sociedade, clique abaixo em "MEU GITHUB" e de uma olhada em alguns dos meus projetos.