DEV Community: Pedro

Criando um simulador de duelos na web

Pedro — Wed, 11 Mar 2026 20:39:28 +0000

Como citei no artigo anterior artigo 3 criei o projeto de organização de decks apenas com o intuito simples de colocar em prática os aspectos técnicos que geralmente são demandados nas entrevistas de emprego. E também porque gosto de codar nessas horas vagas. Por mais que eu tente assumir uma postura de responsabilidade com o código desse side-project é nele que acabo me permitindo errar sem as consequências diretas de um war-room inesperado ou alguma bronca no fim do dia.

Do ponto de vista do back-end, o projeto se encontra em um nível de maturidade bastante interessante. Tenho serviços com domínios bem definidos que trabalham de forma individual sem acoplamento e seguindo os principais microservices patterns. A aplicação é disposta de acordo com as práticas sugeridas pela arquitetura hexagonal.

Assim que eu estava desenvolvendo o community-service(uma das partes integrantes do projeto que permite encontrar jogadores através do recurso de geolocalização) e o vi funcionando na prática, tive a ideia de estender esse projeto. Essa situação me fez lembrar de quando jogava Yu-Gi-Oh! Nos simuladores de código aberto, como edo-pro, ygo-pro, entre outros. Lembro que era possível criar um host de uma sala com regras personalizadas, mas não era possivel delimitar o range para encontrar um duelista. Isso era uma das opções de que sempre senti falta.

Então pensei que seria interessante integrar o "community-service" que desenvolvi, dessa forma poderíamos então encontrar pessoas próximas que também jogam, dando um maior senso de comunidade durante a gameplay. Imediatamente baixei as versões mais usadas atualmente e fiquei um tanto descontente com o visual. Esses simuladores pareciam parados no tempo, especificamente em 2010, sem mudanças significativas de UX. Resolvi então investigar a viabilidade de criar um sistema de duelos online para se integrar não somente com o community-service, mas também com os outros serviços que eu havia desenvolvido no monorepo.

E é aqui que entra o uso do Claude Code para agilizar as coisas. Lembrei desse post aqui que vi no twitter: um teste interessante usando de uma carcaça de card-gaming, pesquisando mais a fundo encontrei também esse artigo referente a um projeto que lida com efeitos semelhantes.

E a maior maior referência visual que me inspirei, foi o poke-holo onde os efeitos de holografia são implementados com maestria para as cartas do Pokémon OCG.

É importante falar do Claude porque foi graças a essa ferramenta que entendi os requisitos necessários para implementar esse sistema de duelos. Descobri que as diferentes versões dos simuladores gratuitos usam um core único, o ocgcore, que é feito inteiramente em C++ sendo os cards escritos em lua. link do projeto: ocgcore-KCG

Esse core funciona como um processo/servidor. Cada ação do jogador vira uma mensagem binária enviada pro core, e o core responde com o novo estado do jogo. O front é essencialmente um renderer burro que exibe o que o core manda.

Basicamente ele é um motor C++ que carrega as regras oficiais de Yu-Gi-Oh, o mesmo usado pelo YGOPro/EDOPro. Ele roda num servidor separado e se comunica via protocolo binário sobre WebSocket. Dessa forma a comunicação com a minha aplicação front vai se dar da seguinte maneira:

Obs: Decidi em deixar o front como react para fortalecer os estudos recentes que tenho feito desse framework.

O duel-system vai ser um serviço isolado do deck-management(mas que usará seus recursos), um sistema web feito em Java/Spring Boot que vai intermediar a comunicação entre o react e o core em C++. Basicamente ele entraria em ação com a biblioteca JNI (Java Native Interface) que vai me permitir chamar funções nativas do ocgcore. O fluxo seria esse aqui:

Nesse ponto, acabei tendo um salto muito grande, do ponto de vista do escopo da atuação. Passei da ideia de projetar o deck-management não apenas como um fim em si mesmo, mas como um meio facilitador de um novo sistema web de duelos. Pretendo torna-lo um sistema tão completo que sinceramente acredito numa recepção bastante positiva da comunidade.

link do repositório, apenas uma poc inicial contendo o front-end em react, ainda sem a implementação do core em C++: deck-management-front-end

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

Pedro — Sun, 01 Mar 2026 22:48:02 +0000

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

Criando um microserviço de organização de decks Yu-Gi-Oh com Spring Boot Parte 02

Pedro — Wed, 16 Apr 2025 19:38:17 +0000

Neste artigo dou continuidade à construção da uma aplicação baseada em microserviços, utilizando Java e Spring Boot para gerenciar cartas e decks de Yu-Gi-Oh, com arquitetura hexagonal. Neste segundo artigo incluo o suporte multi usuário.

Recapitulando

Na Parte 1 abordamos:

Modelagem baseada na orientação a objetos pura, explorando a herança entre cartas (Monster, Spell, Trap)
Foi feita a integração com API externa YGOProDeck
Uso do padrão de projeto factory através da classe:CardFactory e FeignClient
Arquitetura Hexagonal aplicada

Agora evoluímos para:

Persistência com Spring Data JPA (Usando o banco de dados local h2)
Criação de cartas personalizadas via POST
Filtragem de cartas por usuário com o parâmetro ownerId
Endpoint de listagem exclusiva GET /cards/custom?ownerId=

O Cenário Atual

Cada carta agora carrega um campo ownerId, que identifica o usuário que a criou. Isso permite separar cartas criadas manualmente daquelas importadas via API externa.

Obs: O fato de incluirmos um simples campo na nossa aplicação faz com que seja necessário alterar todas as outras estruturas que contavam com a ausência desse campo, por exemplo: o teste de persistencia não incluia esse novo campo, nosso mapper não esperava esse campo e todas as outras estruturas que fazem parte da criação e persistencia desse campo no banco de dados.

Exemplo de objeto `Card` salvo:

{
  "id": 99999999,
  "name": "Teste Dragão Sombrio",
  "type": "MONSTER",
  "ownerId": "user123"
}

Endpoints

POST /cards/custom

Cria uma carta customizada:

POST /cards/custom
Content-Type: application/json

{
  "name": "Teste Dragão Sombrio",
  "type": "MONSTER",
  "attack": 2500,
  "defense": 2100,
  "level": 7,
  "attribute": "DARK",
  "monsterType": "DRAGON",
  "subTypes": ["NORMAL", "EFFECT"],
  "ownerId": "user123"
}

GET /cards/custom?ownerId=user123

Lista apenas as cartas criadas por user123:

[
  {
    "id": 99999999,
    "name": "Teste Dragão Sombrio",
    "type": "MONSTER",
    "ownerId": "user123"
  }
]

Arquitetura Hexagonal Aplicada

Domínio: Card, MonsterCard, SpellCard, TrapCard
Portas: CardPersistencePort
Adapters:
- CardRepositoryAdapter (saida)
- CustomCardQueryController (entrada)
- SaveCardUseCase e ListCustomCardsUseCase (aplicação)
Infraestrutura:
- JpaRepository separados por tipo de carta
- H2 como banco em memória

Destaques

Modularização limpa para cada tipo de carta
ownerId como chave de multi-tenancy
Separando responsabilidade por camadas (entrada, saída, domínio)
Fácil evolução futura com autenticação (JWT)

Próximos Passos

Na próxima parte, vamos abordar a criação e gerenciamento de decks personalizados com persistência e exportação em formato ydk.
Criação do validador das cartas(konami) customizadas.

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

Representação visual da nova implementação:

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

Pedro — Thu, 10 Apr 2025 19:50:08 +0000

Este documento demonstra de forma prática a aplicação do padrão arquitetural Ports and Adapters(Hexagonal) na funcionalidade de busca de cartas do jogo Yu-Gi-Oh usando a API pública YGOProDeck. Seguindo as boas práticas especificadas pela arquitetura em questão: separando as responsabilidades entre domínio, entrada, saída e infraestrutura externa.

Introdução & Objetivos iniciais do projeto

Neste primeiro artigo venho apresentar a organização do projeto e como foi feita a modelagem do sistema. Primeiramente, vamos entender o domínio que está sendo abordado. Nas demais postagens será apresentado os outros micro serviços que compõem a aplicação e a comunicação entre eles através da mensageria.

Yu-Gi-Oh! é um card game estratégico, onde jogadores constroem e enfrentam decks compostos por diferentes tipos de cartas: monstros, mágicas, armadilhas, fusões, entre outras. O jogo possui regras bem estabelecidas e possui uma variedade enorme de cartas, com diferentes efeitos, atributos e classificações.

Este é um projeto feito na intenção de praticar diversos conceitos relevantes da linguagem java que são constantemente exigidos pelo mercado, nele levo em considerações temas como DDD, padrões de projetos, arquitetura de micro serviços e mensageria. O projeto está sendo feito usando o framework Spring Boot e tem como principal objetivo ser uma ferramenta de apoio para organização de decks, permitindo que o usuário:

Consulte cartas diretamente da API pública YGOProDeck

Crie e salve cartas customizadas

Monte decks personalizados, separados em Main Deck, Side Deck e Extra Deck

Valide cartas customizadas por meio de um microserviço de integridade (KonamiService)

Visualize estatísticas e receba notificações futuras (em evolução)

Exporte seus decks no formado ydk.

Modelagem da Solução

A modelagem se deu da seguinte maneira: basicamente o game é formado por um número relativamente pequeno de cartas "principais" que vão servir de base para uma série subdivisões de cartas semelhantes. Por exemplo:


Monstro	Mágica	Armadilha


Modelo abstrato card	classe Java

Considerando as chamadas de API feitas para cada um dos tipos exibidos acima, foi possivel identificar elementos em comum. Levando isso em consideração surge então a ideia de abstrair o que é compartilhado entre essas cartas em uma estrutura única. Dentro do contexto de orientação a objetos essa abordagem é conhecida como herança e foi aplicada através de uma classe abstrata chamada Card.java

No artigo de hoje será desenvolvida a funcionalidade de busca externa de cartas usando OpenFeing como cliente que conta com a seguinte solução:

1. Fluxo da Requisição

2. Endpoint REST - `ExternalCardController`

@RestController
@RequestMapping("/cards")
public class ExternalCardController {

    private final CardSearchPort cardSearchPort;

    public ExternalCardController(CardSearchPort cardSearchPort) {
        this.cardSearchPort = cardSearchPort;
    }

    @GetMapping("/search")
    public ResponseEntity<List<Card>> searchByName(@RequestParam String name) {
        List<Card> cards = cardSearchPort.searchByName(name);
        return ResponseEntity.ok(cards);
    }
}

O controller expõe o endpoint /cards/search e injeta a interface CardSearchPort, que é uma porta do domínio. Ele não sabe como a busca é feita — só encaminha a requisição e retorna o resultado.

3. Porta - `CardSearchPort`

public interface CardSearchPort {
    List<Card> searchByName(String name);
}

Essa interface define o contrato da busca. O domínio não depende de como ou onde a busca acontece — só que ela deve acontecer.

4. Implementação - `YgoProApiClient`

JsonNode response = feignClient.getCardsByName(name);
if (response.has("data")) {
    for (JsonNode node : response.get("data")) {
        CardFactory.fromJson(node).ifPresent(cards::add);
    }
}

O YgoProApiClient é um adapter de saída que implementa CardSearchPort. Ele usa o YgoProFeignClient para consultar a API e o CardFactory para converter JSON em objetos Card.

5. Implementação - `CardFactory`

Aqui usamos o design pattern factory que vai criar uma instância de um objeto de acordo com o tipo especifico de dado que for coletado, por esse motivo temos os condicionais presentes na classe. E por mais verboso que possa parecer todo esse tratamento ele fica totalmente encapsulado dentro do método fromJson.

public class CardFactory {

    public static Optional<Card> fromJson(JsonNode node) {
        String type = node.get("type").asText();
        Long id = node.get("id").asLong();
        String name = node.get("name").asText();
        String desc = node.get("desc").asText();
        String archetype = node.has("archetype") ? node.get("archetype").asText() : null;
        String image = node.get("card_images").get(0).get("image_url").asText();

        if (type.contains("Monster")) {
            int atk = node.path("atk").asInt();
            int def = node.path("def").asInt();
            int level = node.path("level").asInt();
            MonsterAttribute attr = MonsterAttribute.valueOf(node.get("attribute").asText().toUpperCase());
            MonsterType monsterType = MonsterType.valueOf(normalize(node.get("race").asText()));
            Set<MonsterSubType> subTypes = detectMonsterSubtypes(type);

            return MonsterCard.create(id, name, desc, archetype, image, atk, def, level, attr, monsterType, subTypes)
                    .map(c -> (Card) c);
        }

        if (type.contains("Spell")) {
            SpellType spellType = SpellType.valueOf(normalize(node.get("race").asText()));
            return SpellCard.create(id, name, desc, archetype, image, spellType).map(c -> (Card) c);
        }

        if (type.contains("Trap")) {
            TrapType trapType = TrapType.valueOf(normalize(node.get("race").asText()));
            return TrapCard.create(id, name, desc, archetype, image, trapType).map(c -> (Card) c);
        }

        return Optional.empty();
    }

    private static String normalize(String input) {
        return input.trim().toUpperCase().replace("-", "_").replace(" ", "_");
    }

    private static Set<MonsterSubType> detectMonsterSubtypes(String rawType) {
        Set<MonsterSubType> set = EnumSet.noneOf(MonsterSubType.class);
        String[] parts = rawType.toUpperCase().split(" ");
        for (String part : parts) {
            try {
                set.add(MonsterSubType.valueOf(part));
            } catch (IllegalArgumentException ignored) {}
        }
        return set;
    }
}

6. Conclusão

Este exemplo demonstra os princípios da arquitetura hexagonal:

O domínio define a interface (CardSearchPort)
O controller é um adaptador de entrada
O Feign client + factory são adaptadores de saída

Esse modelo permite evoluir ou trocar qualquer parte da aplicação sem afetar o restante, promovendo testabilidade e manutenibilidade.

Repositório do github para consulta: https://github.com/odevpedro/yu-gi-oh-deck-management