Criando uma arquitetura de microsserviços para organização de decks Yu-Gi-Oh com Spring Boot – Parte 03

Jogando fora tudo aquilo que eu tinha feito.

Recentemente consegui focar bastante nesse meu projeto e, por conta disso, consegui observar com calma os erros que acabei cometendo ao longo do caminho. A ideia de iniciar esse projeto ocorreu num período em que era urgente ter ao menos um resquício de portfólio apresentável, em outras palavras: eu estava desempregado.

Essa foi uma forma que encontrei para "mostrar trabalho" para os avaliadores que fossem julgar meu perfil. Dado o contexto das entrevistas em que eu estava participando, minha mente estava fortemente direcionada à orientação a objetos e à arquitetura hexagonal. E tudo isso era muito teórico no momento então resolvi colocar em prática, mas a afobação acabou falando mais alto.

De início, pensei em dois serviços apenas: o organizador de decks e outro serviço que seria responsável por organizar as cartas. Acontece que, antes de pensar em modelar o principal recurso que a minha API oferece: a organização de decks, acabei focando nas unidades que compõem um baralho: as cartas.

Refatorando card-service:

Foi muito legal pensar sobre como era composta uma carta, fazer toda aquela estruturação inicial das classes, criar um modelo abstrato de cards e ter os outros tipos estendendo diretamente dela. Além disso, houve todo o processo de criar as tabelas no banco, lidar com as migrations na prática etc.

Enfim, escrevi muito código que precisei jogar fora, mas foi necessário. Sinceramente, essa foi uma experiência interessante para tornar evidente o fato de que não podemos nos apegar ao código, mas sim à solução. Não foi fácil fazer isso, já que eu acabei me apegando às primeiras versões da aplicação e da progressão que estava acontecendo nos dois primeiros artigos.

Mas agora preciso admitir que estava quase tudo errado. Isso porque a entidade CARD não fazia o menor sentido dentro do card-service, já que esse módulo da aplicação serve apenas como um meio pelo qual o serviço de deck usa para realizar as buscas das cartas, dessa forma não há justificativa para a persistência em um banco de dados.

Agora, card-service é apenas um recurso de consultas na biblioteca de cartas do Yu-Gi-Oh! Que abrange diversos filtros, é o serviço mais leve do projeto até agora. Segue o fluxo do seu funcionamento:

O serviço de deck segue na mesma intenção anterior: ser uma coleção de cartas, a diferença é que agora essas CARTAS são reconhecidas por seus IDs e não por suas entidades do banco de dados. Já que o card-service permite a consulta de múltiplas cartas por id, então o front-end consegue renderizar as cartas na tela batendo diretamente nesse endpoint.

card-creator-service:

A fim de implementar event driven architecture(EDA), resolvi criar um novo microservice: card-creator-service(que agora não é simplesmente um endpoint em cards-service). Um serviço que nos permite criar novas cartas customizadas seguindo todas as especificações de composição de card. A mensageria aqui vai entrar juntamente com a ideia de validar/autorizar a criação daquela carta. O fluxo seria: o usuário cria uma carta e ela surge com o status pendente: esperando a avaliação do serviço que vai inferir a viabilidade da carta, dizendo se ela é aceitável. Este serviço vai se chamar konami-validator-service.

shared-domain

Shared-domain surge da necessidade de tirar a interdependência entre os microservices: é um módulo Java puro (sem Spring, sem banco, sem dependências externas) que contém apenas os enums que representam o vocabulário do universo Yu-Gi-Oh: tipos de carta, atributos de monstro, subtipos e raças.

Ele existe porque múltiplos serviços precisam falar a mesma língua. Sem ele, cada serviço teria sua própria cópia de CardType, MonsterAttribute e afins, todo esse código duplicado poderia divergir o tempo. Com ele, todos importam de uma única fonte da verdade, garantindo consistência em todo o projeto sem criar acoplamento de runtime entre os serviços.

Abri a imagem com maior resolução




Recursos futuros: Pretendo tornar esse projeto o mais over engineering possivel. A ideia é estudar os recursos que gradualmente vão sendo adicionados e ter uma implementação prática para os conceitos que geralmente são exigidos pelo mercado. Futuramente pretendo adicionar: Geolocalização, WebSocket com STOMP, Elasticsearch, etc

Repositório: github.com/odevpedro/yu-gi-oh-deck-management