Criando uma arquitetura de microsserviços para organização de decks Yu-Gi-Oh com Spring Boot – Parte 03
Published: (March 1, 2026 at 05:48 PM EST)
4 min read
Source: Dev.to
Source: Dev.to
[](https://dev.to/odevpedro)
---
## 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. 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:
[](https://media2.dev.to/dynamic/image/width=800,height=%2Cfit=scale-down,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fd2rxnxvt2ip8ooids60c.png)
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. Como o *card‑service* permite a consulta de múltiplas cartas por ID, 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*). Esse serviço nos permite criar novas cartas customizadas seguindo todas as especificações de composição de card. A mensageria entra juntamente com a ideia de validar/autorizar a criação daquela carta.
O fluxo seria:
1. O usuário cria uma carta.
2. A carta surge com o status **pendente** (esperando a avaliação).
3. O serviço **konami‑validator‑service** infere a viabilidade da carta e decide se ela é aceitável.
---
## **shared‑domain**
**shared‑domain** surge da necessidade de eliminar 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` etc., e esse código duplicado poderia divergir ao longo do tempo. Com um único módulo, todos importam de uma única fonte da verdade, garantindo consistência em todo o projeto sem criar acoplamento de runtime entre os serviços.
[Abra a imagem com maior resolução](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/dqj4ptbp3zdpf7k5ig5y.png)g)
**Recursos futuros:** Pretendo tornar esse projeto o mais *over engineering* possível. 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](https://github.com/odevpedro/yu-gi-oh-deck-management)