CP3 - Projeto de Microservices Marketplace 🛒

Este projeto é uma entrega para a disciplina de CP3, simulando um sistema de marketplace no estilo Mercado Livre. A aplicação permite que Lojas (Vendedores) publiquem anúncios e Clientes (Compradores) comprem esses produtos.

O projeto foi desenvolvido como um Monólito Modular em Spring Boot com Thymeleaf para as views.

---

🚀 Tecnologias Utilizadas

• Java 21
• Spring Boot 3.5.7
• Spring Web: Para controladores MVC e exposição de páginas.
• Spring Data JPA: Para persistência de dados e abstração de queries.
• Thymeleaf: Motor de templates para renderização das views no servidor (SSR).
• H2 Database: Banco de dados em memória para agilidade no desenvolvimento e testes.
• Lombok: Para reduzir código boilerplate (Getters, Setters, Construtores).
• Bootstrap 5: Para estilização do front-end via CDN.

---

🛠️ Como Executar o Projeto

Pré-requisitos

• JDK 21 (ou superior) instalado.
• Uma IDE (IntelliJ, VSCode) ou o Gradle na linha de comando.

Passos para Execução

1. Clone este repositório.
2. Abra o projeto em sua IDE.
3. Execute a classe principal Cp6JavaApplication.java.
4. Acesse a aplicação no seu navegador:
   • http://localhost:8080/
   • (Você será redirecionado para /marketplace).

Acessando o Banco de Dados (H2 Console)

Para visualizar os dados (tabelas, usuários, produtos) em tempo real:

1. Com a aplicação rodando, acesse: http://localhost:8080/h2-console
2. Na tela de login, preencha os campos exatamente assim:
   • JDBC URL: jdbc:h2:mem:marketplace_db
   • User Name: sa
   • Password: password
3. Clique em Connect.

---

🧪 Fluxo de Teste (Caminho Feliz)

Para testar a funcionalidade principal da aplicação:

1. (Admin) Criar Usuários:

   • Acesse http://localhost:8080/admin/users/new
   • Crie um usuário com a role CLIENTE (Ex: "Cliente 1").
   • Crie outro usuário com a role LOJA (Ex: "Loja 2").
   • (Nota: Os IDs 1 (Cliente) e 2 (Loja) são usados como mock de login nos controladores para simplificar o projeto).

2. (Admin) Cadastrar Produto Base:

   • Acesse http://localhost:8080/admin/products/new
   • Cadastre um produto (Ex: "iPhone 15", Categoria "ELETRONICOS").

3. (Loja) Criar Anúncio:

   • Acesse http://localhost:8080/store/ads/new
   • Selecione o "iPhone 15", defina um preço (ex: 7000.00) e estoque (ex: 10).
   • Clique em "Publicar Anúncio". Você será redirecionado para a home.

4. (Cliente) Comprar Anúncio:

   • Na página inicial (/marketplace), você verá o anúncio criado.
   • Clique em "Ver Detalhes".
   • Na página de detalhes, escolha a quantidade e clique em "Comprar Agora".

5. (Cliente) Ver Pedidos:

   • Você será redirecionado para "Meus Pedidos" (http://localhost:8080/order/my-orders/1).
   • Seu pedido estará lá com status PENDING.
   • Verificação: Se você acessar o H2 Console, verá que o estoque do anúncio foi abatido.

---

🏛️ Análise Arquitetural e Diagramas

A pergunta central da atividade é: "Você usaria microserviços?"

Resposta: Sim. Um sistema de marketplace é um exemplo clássico para a aplicação de uma arquitetura de microserviços.

O projeto prático deste CP foi entregue como um Monólito Modular para atender aos requisitos de prazo e simplicidade, mas sua estrutura de pacotes (user, catalog, order) foi projetada para espelhar a separação de domínios que os microserviços teriam.

Por que Microserviços?

Um marketplace real possui domínios de negócio complexos e com necessidades distintas:

• Identidade: Cadastro de clientes e lojas.
• Catálogo: Gerenciamento de produtos e anúncios.
• Pagamentos: Processamento de transações.
• Logística: Cálculo de frete, rastreio e entrega.
• Pedidos: Orquestração do fluxo de compra.

Dividir esses domínios em microserviços oferece vantagens cruciais:

1. Escalabilidade Independente: Em eventos de alta demanda (como Black Friday), o serviço de Catálogo e Pagamentos precisa de 100x mais recursos que o serviço de Identidade. Com microserviços, podemos escalar apenas os serviços necessários, otimizando custos. Em um monólito, teríamos que escalar a aplicação inteira.

2. Resiliência (Tolerância a Falhas): Se o serviço de Logística (cálculo de frete) falhar, o restante do site continua funcionando. Os clientes ainda podem navegar e adicionar ao carrinho. Em um monólito, uma falha em um módulo não essencial pode derrubar todo o sistema.

3. Autonomia de Times e Manutenção: Times diferentes podem evoluir seus serviços de forma independente. O "Time de Pagamentos" pode adicionar o PIX como nova forma de pagamento e fazer o deploy sem precisar coordenar com o "Time de Catálogo", que pode estar alterando o algoritmo de busca. Isso acelera a entrega de valor.

Diagrama da Arquitetura de Microserviços (Proposta)

Abaixo está um diagrama de componentes de alto nível de como a arquitetura de microserviços ideal seria estruturada.

%% Sintaxe corrigida do diagrama Mermaid
graph TD
    %% 'client_sub' é um ID. O texto em CITAÇÕES é o título.
    subgraph client_sub ["Cliente (Browser/App)"]
        %% O texto em CITAÇÕES é o label seguro para o node
        WebApp("Front-end Web (Thymeleaf/React)")
    end

    subgraph infra_sub ["Infraestrutura Central"]
        Gateway("API Gateway")
        Discovery("Service Discovery")
    end

    subgraph services_sub ["Domínios de Negócio (Microserviços)"]
        UserService("Serviço de Usuários")
        CatalogService("Serviço de Catálogo")
        OrderService("Serviço de Pedidos")
        PaymentService("Serviço de Pagamentos")
        LogisticsService("Serviço de Logística")
    end

    subgraph db_sub ["Bancos de Dados (Separados)"]
        %% Usando [(Database)] para a forma de cilindro
        UserDB[("DB Usuários")]
        CatalogDB[("DB Catálogo")]
        OrderDB[("DB Pedidos")]
        PaymentDB[("DB Pagamentos")]
        LogisticsDB[("DB Entregas")]
    end

    %% Conexões
    WebApp --> Gateway

    Gateway --> UserService
    Gateway --> CatalogService
    Gateway --> OrderService
    Gateway --> PaymentService
    Gateway --> LogisticsService

    %% Conexões com Bancos
    UserService --- UserDB
    CatalogService --- CatalogDB
    OrderService --- OrderDB
    PaymentService --- PaymentDB
    LogisticsService --- LogisticsDB

    %% Comunicação entre serviços
    OrderService -.-> PaymentService
    OrderService -.-> LogisticsService
    OrderService -.-> CatalogService

Loading

---

🏗️ Estrutura do Projeto (Monólito Modular)

O projeto segue uma arquitetura em camadas, separada por domínios de negócio:

com.fiap.marketplace.Cp6_Java
│
├── catalog/ (Domínio de Catálogo)
│   ├── controller/ (ProductAdminController, AdStoreController, MarketplaceController)
│   ├── dto/        (AdCreateDTO, AdResponseDTO, ProductCreateDTO, etc.)
│   ├── enums/      (CategoryProduct)
│   ├── models/     (Ad, Product)
│   ├── repositories/ (AdRepository, ProductRepository)
│   └── service/      (CatalogService)
│
├── order/ (Domínio de Pedidos)
│   ├── controller/ (OrderController)
│   ├── dto/        (OrderCreateDTO, OrderResponseDTO)
│   ├── enums/      (OrderStatus)
│   ├── models/     (Order)
│   ├── repositories/ (OrderRepository)
│   └── service/      (OrderService)
│
├── user/ (Domínio de Usuários)
│   ├── controller/ (UserController)
│   ├── dto/        (UserCreateDTO, UserResponseDTO)
│   ├── enums/      (UserRole, UserStatus)
│   ├── models/     (User)
│   ├── repositories/ (UserRepository)
│   └── service/      (UserService)
│
├── controller/ (Controladores Globais)
│   └── HomeController.java (Redireciona / para /marketplace)
│
└── Cp6JavaApplication.java (Ponto de entrada)

---

📝 Documentação das Simplificações

Para viabilizar a entrega deste CP no prazo, as seguintes simplificações de escopo foram decididas e documentadas:

1. Arquitetura Monolítica: Conforme discutido, o projeto é um Monólito Modular, não uma arquitetura de microserviços real. A separação de domínios é apenas lógica (pacotes Java).
2. Banco de Dados em Memória: Foi utilizado o H2 Database em memória. Todos os dados são perdidos quando a aplicação é reiniciada.
3. Sem Autenticação/Segurança: Não há sistema de login (ex: Spring Security). O acesso às áreas de Admin e Loja é feito por URLs diretas. Os IDs de usuário (Cliente e Loja) são fixos (hardcoded) nos controladores para simular os diferentes perfis.
4. Sistema de Pagamentos (Mock): O pagamento não é processado. Ao "comprar", o sistema apenas verifica o estoque, dá baixa no item e cria um Order no banco com status PENDING.
5. Sistema de Logística (Mock): Não há integração com APIs de frete ou entrega. O fluxo termina no OrderService.
6. Sem Carrinho de Compras: A compra é limitada a um tipo de produto (anúncio) por vez. Não é possível adicionar múltiplos itens diferentes em um mesmo pedido.
7. Flyway Desabilitado: Embora o Flyway esteja no build.gradle, ele foi desabilitado no application.yaml em favor da propriedade hibernate: ddl-auto: update para facilitar a prototipação rápida.

---

👨‍💻 Grupo

• Luiz Eduardo Da Silva Pinto e RM55213