10 de agosto de 2026
Sistema Inteligente de Gestão de Vendas com Recomendações
Luana Quinaglia Maistro; Vinicius Santos Andrade
DOI: 10.22167/2675-6528-202601105
Artigo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.
Resumo
A gestão eficiente de vendas e estoque mostrou-se crucial para a competitividade empresarial em mercados dinâmicos e orientados por dados. Desenvolveu-se o Nexsell, um Sistema Inteligente de Gestão de Vendas com funcionalidades de recomendações personalizadas, com o objetivo de integrar controle operacional e inteligência de dados em uma solução acessível a pequenas e médias empresas. O sistema foi arquitetado com base nos princípios de Clean Architecture e Domain-Driven Design, utilizando .NET 8, PostgreSQL e Entity Framework Core no backend, e React 19 com TypeScript no frontend. Implementaram-se seis módulos funcionais abrangentes, incluindo cadastro de produtos, gestão de clientes, registro de vendas, controle de estoque, recomendações inteligentes e relatórios gerenciais interativos. As recomendações personalizadas foram fornecidas via Recombee, uma plataforma externa, com base no histórico de compras e perfil dos clientes. Validou-se o sistema por meio de 212 testes unitários em xUnit e testes de integração automatizados, que avaliaram a qualidade das sugestões geradas pelo algoritmo com métricas Precision@K e Recall@K em 55 cenários simulados. Os resultados demonstraram a integração bem-sucedida de funcionalidades operacionais tradicionais com um módulo de recomendações inteligentes, apresentando Precision@5 médio de 19,3% e Recall@5 médio de 48,2%, consistentes com o esperado para catálogos de pequeno porte. A arquitetura adotada garantiu manutenibilidade, testabilidade e resiliência a falhas externas, contribuindo para uma solução robusta e adaptável às necessidades do mercado.
Palavras-chave: Arquitetura de software; Automação; Clean Architecture; Domain-Driven Design; Filtragem colaborativa.
1. Introdução
A transformação digital redefiniu profundamente o panorama empresarial, exigindo das organizações uma adaptação contínua e a adoção de estratégias inovadoras para manter a competitividade. Neste cenário, a gestão eficiente de vendas e estoque emergiu como um pilar fundamental para o sucesso, especialmente em mercados dinâmicos e crescentemente orientados por dados. A capacidade de processar e analisar grandes volumes de informações para otimizar operações e prever tendências de consumo tornou-se um diferencial estratégico. Laudon e Laudon (2023) enfatizam que sistemas de informação bem estruturados deixaram de ser um luxo para se tornarem uma necessidade imperativa, pois empresas que não conseguem controlar suas operações e embasar decisões em dados correm o risco de perder relevância. Contudo, pequenas e médias empresas (PMEs) frequentemente enfrentam desafios significativos na implementação de soluções integradas, muitas vezes dependendo de ferramentas desconectadas ou processos manuais que limitam severamente sua capacidade de análise e crescimento.
Paralelamente a esta evolução, a inteligência artificial (IA) tem revolucionado a experiência de compra e a gestão comercial. Dentre suas diversas aplicações, os sistemas de recomendação destacam-se como uma das mais bem-sucedidas vertentes do *machine learning*, conforme apontam Ricci, Rokach e Shapira (2015). Esses sistemas são capazes de analisar o comportamento dos consumidores, como histórico de compras e preferências, para sugerir produtos relevantes de forma personalizada. A eficácia dessa abordagem é amplamente comprovada por gigantes do mercado como Amazon e Netflix, que utilizam algoritmos sofisticados de filtragem colaborativa e baseada em conteúdo para elevar significativamente as taxas de conversão, aumentar o valor médio das vendas e aprimorar a satisfação do cliente. A personalização da experiência de compra, antes restrita a grandes corporações com vastos recursos tecnológicos, tornou-se um fator decisivo para engajar clientes e impulsionar o crescimento do negócio em qualquer escala.
Apesar do potencial transformador da inteligência artificial, a implementação de sistemas inteligentes e integrados permanece um desafio considerável para pequenas e médias empresas. Os altos custos de desenvolvimento, a complexidade de integração com infraestruturas existentes e a escassez de conhecimento técnico especializado frequentemente inviabilizam a adoção dessas tecnologias avançadas. Nesse contexto, a engenharia de software moderna busca soluções que equilibrem funcionalidade, facilidade de uso e viabilidade econômica, conforme preconiza Sommerville (2011), especialmente ao desenvolver sistemas para organizações com recursos limitados. A necessidade de sistemas que sejam não apenas funcionais, mas também adaptáveis e escaláveis, ressalta a importância de decisões arquiteturais bem fundamentadas. Richards e Ford (2020) argumentam que a arquitetura de software transcende a mera escolha de tecnologias, envolvendo decisões estratégicas sobre como estruturar sistemas para atender aos requisitos de negócio, garantindo adaptabilidade às mudanças futuras e resiliência a falhas. Princípios como Clean Architecture e Domain-Driven Design (DDD) são cruciais para construir sistemas robustos e manuteníveis. O DDD, conforme proposto por Evans (2003), foca na modelagem do domínio de negócio, utilizando conceitos como entidades e objetos de valor para encapsular regras de negócio e garantir a integridade dos dados, uma abordagem que Vernon (2013) detalha como essencial para a lógica de validação. A Clean Architecture, por sua vez, promove a separação de preocupações em camadas, isolando as regras de negócio da infraestrutura e da interface do usuário, o que facilita a testabilidade, a manutenibilidade e a escalabilidade do sistema ao longo do tempo, características essenciais para sistemas que precisam evoluir e se integrar a serviços externos de forma confiável.
Diante da lacuna existente entre a necessidade das pequenas e médias empresas por uma gestão de vendas e estoque eficiente e a complexidade de implementar soluções tecnológicas avançadas, este trabalho justifica-se pela crescente demanda por democratização de ferramentas inteligentes e pela oportunidade de aplicar conceitos de engenharia de software de ponta, arquitetura de sistemas e inteligência artificial em um contexto prático e relevante para o mercado. Assim, o objetivo deste artigo é apresentar o desenvolvimento de um sistema inteligente de gestão de vendas que integre funcionalidades operacionais tradicionais com recursos de recomendações personalizadas, oferecendo uma solução acessível e robusta para pequenas e médias empresas otimizarem suas operações e aprimorarem a experiência do cliente por meio de sugestões baseadas em seu histórico de compras.
2. Material e Métodos
A pesquisa caracterizou-se como aplicada, visando solucionar um problema prático do mercado, conforme a classificação de Gil (2002). Seus objetivos foram exploratórios e descritivos, buscando compreender os desafios de gestão comercial em pequenas empresas e desenvolver uma solução tecnológica funcional. A abordagem metodológica adotada foi a pesquisa aplicada com desenvolvimento de prova de conceito, focando na construção e validação técnica de um sistema inteligente de gestão de vendas. Este processo ocorreu em ciclos iterativos, com avaliação contínua dos resultados, seguindo princípios de metodologia ágil, sem envolver a participação direta de usuários finais em um ambiente operacional real.
O contexto do estudo abrangeu o cenário de pequenas e médias empresas que buscam otimizar a gestão de vendas e estoque por meio de tecnologias avançadas. O local de desenvolvimento foi o ambiente de pesquisa e desenvolvimento, sem um local físico específico de aplicação em campo. O período de execução da pesquisa não foi explicitamente delimitado, mas o desenvolvimento do sistema ocorreu em ciclos iterativos, refletindo uma abordagem contínua. A unidade de análise principal foi o sistema Nexsell, um software de gestão de vendas com funcionalidades de recomendação, avaliado quanto à sua arquitetura, implementação e desempenho técnico.
Para a validação do sistema, não se utilizou uma população ou amostra de usuários reais, mas sim um estudo de caso com simulação de operações comerciais. Os dados empregados foram sintéticos, elaborados com base em padrões reais de negócio para garantir relevância. Foram criados cenários específicos que contemplaram cinco perfis distintos de clientes e seus respectivos padrões de compra. Essa abordagem permitiu avaliar a qualidade das recomendações geradas pelo sistema em condições controladas, sem a necessidade de interação com um ambiente de produção real ou dados sensíveis de clientes.
A unidade de análise para a validação das recomendações consistiu em 50 produtos sintéticos, distribuídos igualmente em cinco categorias: Informática, Eletrônicos, Livros, Esportes e Casa. Para cada um dos cinco perfis de consumo modelados (Programador, Gamer, Leitor, Esportista e HomeOffice), foram instanciados onze clientes simulados, totalizando 55 cenários de avaliação. Esses cenários foram cruciais para testar a capacidade do algoritmo de recomendação em diferentes contextos de preferência e histórico de compras, garantindo uma análise abrangente do comportamento do sistema.
O sistema Nexsell foi desenvolvido seguindo os princípios de Domain-Driven Design (DDD) e Clean Architecture (Richards; Ford, 2020), que guiaram as decisões arquiteturais e táticas de modelagem. O backend foi implementado em .NET 8, utilizando PostgreSQL como banco de dados e Entity Framework Core para acesso a dados. A lógica de negócio foi exposta por meio de uma API REST, organizada em quatro camadas (Domain, Application, Infrastructure e API) e documentada com Swagger/OpenAPI, facilitando a integração e o consumo dos serviços por outras aplicações.
O frontend do sistema foi construído como uma aplicação web em React 19 com TypeScript, utilizando Ant Design para componentes de interface, Zustand para gerenciamento de estado e Axios para requisições HTTP. A ferramenta Vite foi empregada para build e desenvolvimento, otimizando a velocidade. O sistema contemplou seis módulos principais: cadastro e controle de produtos, gestão de clientes, registro de vendas, controle de estoque, recomendações inteligentes e relatórios gerenciais. Uma biblioteca TypeScript compartilhada, contendo Value Objects e casos de uso, foi publicada via GitHub Packages para reutilização.
A funcionalidade de gestão de clientes integrou-se à API ViaCEP para preenchimento automático de endereços, aprimorando a experiência do usuário e a precisão dos dados. O módulo de recomendações inteligentes foi viabilizado pela integração com o Recombee, uma plataforma especializada em sistemas de recomendação. Essa escolha permitiu focar na aplicação prática da inteligência artificial, delegando a complexidade do desenvolvimento de algoritmos de *machine learning* ao serviço externo. Os dados de interação, como histórico de compras, foram enviados ao Recombee via API para gerar sugestões personalizadas.
O desenvolvimento do sistema seguiu uma pipeline de quatro etapas principais. Inicialmente, realizou-se a análise e modelagem, com levantamento de requisitos e definição da arquitetura. Em seguida, ocorreu a implementação, com a criação de funcionalidades e a aplicação de testes automatizados a cada nova funcionalidade. A terceira etapa envolveu a integração com o serviço Recombee, configurando o envio de eventos de compra e o consumo das recomendações. Por fim, procedeu-se à validação final, com simulações de cenários e coleta de métricas de qualidade para avaliar o desempenho do sistema.
A estratégia de testes foi estruturada em três níveis complementares, conforme preconizado por Sommerville (2011), para garantir a qualidade do software. Foram realizados testes unitários de domínio, cobrindo entidades e objetos de valor, totalizando 154 testes. Adicionalmente, 58 testes unitários de aplicação foram executados para validar os serviços da camada de aplicação, utilizando o framework xUnit e a biblioteca Moq para criação de dublês. Esses testes verificaram comportamentos, transições de estado, regras de negócio e casos de falha esperados, assegurando a robustez interna do sistema.
Testes de integração automatizados foram elaborados e executados no projeto Teste.Integration, utilizando o framework xUnit, diretamente contra a API do Recombee. A qualidade das recomendações foi mensurada por meio das métricas Precision@K e Recall@K, amplamente reconhecidas na literatura de sistemas de recomendação (Ricci, Rokach e Shapira, 2015). Para cada um dos 55 cenários de avaliação, aplicou-se a técnica de *train/test split*, onde quatro compras foram usadas para treino e duas retidas como *ground truth* para avaliação, com K=5 para as métricas.
A comunicação com o Recombee ocorreu em três momentos-chave do fluxo de negócio. No cadastro ou atualização de um produto, o serviço RecomendacaoService sincronizou automaticamente o item, enviando propriedades como nome, categoria e preço, que compõem o esquema de dados do Recombee. Ao confirmar uma venda, o sistema registrou automaticamente um evento AddPurchase para cada item vendido, fornecendo o principal insumo para o algoritmo de filtragem colaborativa. A visualização de um item pelo cliente também gerou interações, contribuindo para o aprendizado do algoritmo.
Não foram aplicados procedimentos éticos formais, uma vez que a pesquisa envolveu o desenvolvimento de um sistema e sua validação com dados sintéticos, sem a participação direta de seres humanos ou a coleta de dados pessoais. A principal limitação metodológica identificada foi a utilização de dados sintéticos para a avaliação das recomendações. Embora essa abordagem tenha sido suficiente para validar a integração técnica e o funcionamento do algoritmo, ela não substitui uma avaliação com dados reais de operação em um ambiente de produção, o que poderia oferecer *insights* adicionais sobre o desempenho em condições de uso real.
3. Resultados e Discussão
O desenvolvimento do sistema Nexsell, objeto central deste trabalho, foi pautado por uma arquitetura robusta e princípios de engenharia de software modernos, visando não apenas a funcionalidade, mas também a manutenibilidade, escalabilidade e extensibilidade. A escolha do Domain-Driven Design (DDD) e da Clean Architecture, conforme preconizado por Evans (2003) e Richards e Ford (2020), respectivamente, revelou-se fundamental para a organização do código em quatro camadas distintas: Domain, Application, Infrastructure e API. Essa separação de responsabilidades é um pilar para sistemas complexos, garantindo que as regras de negócio permaneçam isoladas de detalhes tecnológicos, o que facilita a evolução e a adaptação a novas demandas de mercado.
A camada de Domínio, por exemplo, concentrou as entidades de negócio essenciais, como Cliente, Produto, Estoque, Venda, ItemVenda e Usuário. Cada uma dessas entidades foi modelada com um encapsulamento rigoroso, utilizando *setters* privados e métodos de domínio que asseguram a integridade dos dados e o cumprimento das invariantes de negócio. Essa abordagem está em consonância com a filosofia do DDD, que enfatiza a modelagem de um domínio rico e expressivo. Além disso, objetos de valor como CPF, CNPJ, Documento, Contato e Endereço foram implementados como tipos imutáveis com validação embutida. Essa prática, defendida por Vernon (2013), garante que a lógica de validação resida no próprio tipo, evitando a dispersão de regras de validação por toda a aplicação e promovendo a consistência dos dados desde a sua criação. A imutabilidade desses objetos de valor contribui para a robustez do sistema, prevenindo alterações indesejadas após a sua inicialização.
A camada de Infraestrutura foi responsável pela persistência dos dados, empregando o Entity Framework Core 8 e aplicando os padrões Repository e Unit of Work. Esses padrões são cruciais para abstrair as operações de acesso a dados, permitindo que a lógica de negócio na camada de Domínio não precise conhecer os detalhes específicos do banco de dados. Durante o desenvolvimento, o SQLite foi utilizado pela sua simplicidade de configuração, ideal para ambientes de prototipagem e testes. Contudo, a migração para PostgreSQL em ambiente de produção, facilitada pelo próprio Entity Framework Core, demonstrou a flexibilidade da arquitetura. A capacidade de aplicar migrações automaticamente na inicialização da aplicação eliminou a necessidade de *scripts* manuais, reduzindo a chance de erros e agilizando o *deploy*. Essa adaptabilidade a diferentes sistemas de banco de dados, sem impacto nas regras de negócio, é um testemunho da eficácia da Clean Architecture em desacoplar as preocupações técnicas das regras de negócio. O modelo de dados resultante, dividido em domínios de clientes e comercial, é ilustrado por diagramas de entidades que detalham as relações e atributos.
Figura 1. Diagrama de entidades do domínio de clientes
Fonte: Resultados originais da pesquisa
A Figura 1, que apresenta o diagrama de entidades do domínio de clientes, detalha a estrutura de dados para o gerenciamento de informações cruciais sobre os consumidores. Observa-se a entidade `Clientes` como o cerne, contendo atributos como `Id`, `Nome`, `DocumentoNumero`, `DocumentoTipo` e `Ativo`, além de `DataCadastro`. Essa entidade se relaciona com `ClienteEnderecos` e `ClienteContatos`, permitindo o registro de múltiplos endereços e contatos para um mesmo cliente. A modelagem de `ClienteEnderecos` com campos como `CEP`, `Logradouro`, `Numero`, `Complemento`, `Bairro`, `Cidade` e `UF` reflete a necessidade de dados geográficos detalhados para operações comerciais e logísticas. A integração com a API ViaCEP, mencionada na metodologia, otimiza o preenchimento desses campos, reduzindo erros e melhorando a experiência do usuário, o que é um diferencial prático para pequenas empresas que buscam eficiência. A entidade `ClienteContatos`, por sua vez, permite armazenar `Telefone`, `Celular` e `Email`, oferecendo múltiplos canais de comunicação com o cliente. Essa granularidade na modelagem de dados de clientes é essencial para um sistema de gestão de vendas que visa a personalização e o relacionamento duradouro, como defendido por Laudon e Laudon (2023), que enfatizam a importância de sistemas de informação bem estruturados para a competitividade empresarial.
Figura 2. Diagrama de entidades do domínio comercial
Fonte: Resultados originais da pesquisa
A Figura 2, que ilustra o domínio comercial, complementa a visão do sistema ao apresentar as entidades `Produtos`, `Estoques`, `Vendas`, `ItensVenda` e `Usuarios`. A entidade `Produtos` inclui `Id`, `Codigo`, `Nome`, `Descricao`, `PrecoUnitario`, `Categoria`, `Ativo` e `DataCadastro`, fornecendo uma base sólida para o catálogo de produtos. A integração automática com o Recombee para sincronização de produtos, conforme detalhado adiante, garante que as recomendações sejam sempre baseadas em dados atualizados. A entidade `Estoques` gerencia a `Quantidade`, `QuantidadeMinima` e `Localizacao` de cada produto, permitindo um controle preciso do inventário e a geração de alertas para níveis baixos de estoque, uma funcionalidade crítica para evitar perdas de vendas e otimizar a gestão de capital de giro em pequenas empresas. As `Vendas` são registradas com `Id`, `ClienteId`, `DataVenda`, `Status`, `FormaPagamento` e `Observacao`, enquanto `ItensVenda` detalha cada produto incluído em uma venda, com `ProdutoId`, `ProdutoNome`, `Quantidade` e `PrecoUnitario`. Essa estrutura permite o rastreamento completo do ciclo de vendas, desde a criação até a confirmação e o cancelamento, com a baixa automática de estoque e o envio de eventos de compra ao Recombee, demonstrando a interconexão e a automação dos processos de negócio. A entidade `Usuarios` gerencia o acesso ao sistema com `Id`, `Nome`, `Email`, `SenhaHash` e `Role`, implementando um controle de acesso baseado em perfis, essencial para a segurança e a governança do sistema.
A camada API, implementada em ASP.NET Core 8, expõe a lógica de negócio por meio de uma interface RESTful. Essa abordagem é amplamente reconhecida por sua flexibilidade e compatibilidade com diversas aplicações clientes. Os *endpoints* foram distribuídos entre módulos de Autenticação, Clientes, Produtos, Estoque, Vendas, Recomendações e Relatórios. A documentação interativa da API, gerada automaticamente com Swagger/OpenAPI, facilitou o consumo e os testes dos *endpoints*. A OpenAPI Specification (OPENAPI INITIATIVE, 2015) é um padrão que permite a criação automatizada de SDKs, agilizando a integração entre *frontend* e *backend* e reduzindo a carga de trabalho de desenvolvimento. Essa conformidade com padrões abertos é um indicativo da maturidade do projeto e de sua capacidade de integração com ecossistemas externos.
A separação em camadas, conforme a Clean Architecture, é um resultado arquitetural de grande valor. Richards e Ford (2020) descrevem como características arquiteturais essenciais a manutenibilidade, extensibilidade e testabilidade. O Nexsell, ao isolar responsabilidades, garante que modificações em uma camada não afetem as outras, facilitando a manutenção. A extensibilidade é favorecida pelo uso de interfaces e injeção de dependência, permitindo a fácil substituição de componentes. A testabilidade é viabilizada pelo desacoplamento entre as camadas, possibilitando a escrita de testes unitários e de integração eficazes.
O *frontend* do sistema foi construído como uma aplicação web em React 19 com TypeScript, utilizando Ant Design para componentes de interface, Zustand para gerenciamento de estado e Axios para requisições HTTP. A escolha do React (REACT, 2013) deve-se à sua maturidade e vasta comunidade, que garantem um ecossistema robusto e em constante evolução. O Ant Design (DEVOGRAPHICS, 2024), por sua vez, é uma biblioteca de componentes amplamente utilizada em aplicações corporativas, oferecendo mais de 50 componentes responsivos e facilitando a manutenção da consistência visual. O Zustand foi selecionado pela sua simplicidade no gerenciamento de estado global, abstraindo detalhes de implementação e oferecendo flexibilidade organizacional. A biblioteca Axios, embora existam alternativas nativas como Fetch API, foi preferida pelos seus facilitadores, como o tratamento automático de *status codes*, a capacidade de tratar erros HTTP como exceções e a facilidade de uso de *interceptors*, que reduzem o código repetitivo e padronizam o comportamento das requisições. A ferramenta Vite otimizou o processo de *build* e desenvolvimento, contribuindo para a agilidade na entrega. Uma biblioteca TypeScript compartilhada, contendo *Value Objects* e casos de uso, foi publicada via GitHub Packages, promovendo a reutilização de código e reforçando a adaptabilidade da aplicação, permitindo que o *frontend* evolua independentemente da lógica de domínio invariante.
O sistema Nexsell contemplou seis módulos principais, cada um com um conjunto de funcionalidades projetadas para otimizar a gestão comercial de pequenas empresas. A Tabela 1 detalha esses módulos e suas principais funcionalidades.
Tabela 1. Módulos implementados e suas funcionalidades principais
|
Módulo |
Funcionalidades |
|
Clientes |
Cadastro com CPF/CNPJ, contatos e endereços múltiplos, ativação e inativação |
|
Produtos |
Cadastro por código, categoria e preço, sincronização automática com o Recombee |
|
Estoque |
Controle de quantidade, alertas de estoque abaixo do mínimo, entradas e saídas (No frontend, integrado com a tela de produtos) |
|
Vendas |
Criação, adição e remoção de itens, confirmação com baixa automática de estoque, cancelamento |
|
Recomendações |
Integração com Recombee, sugestões personalizadas por cliente (No frontend integrado junto com a tela de clientes) |
|
Relatórios |
Resumo de vendas por período, produtos mais vendidos, clientes que mais compraram e posição do estoque |
Fonte: Resultados originais da pesquisa
A Tabela 1 apresenta um resumo conciso dos módulos implementados e suas funcionalidades, demonstrando a abrangência do sistema Nexsell. O módulo de `Clientes` oferece cadastro completo com CPF/CNPJ, múltiplos contatos e endereços, além de ativação e inativação, o que é crucial para manter um banco de dados de clientes atualizado e preciso, suportando estratégias de segmentação e relacionamento. O módulo de `Produtos` permite o cadastro por código, categoria e preço, e se destaca pela sincronização automática com o Recombee, garantindo que o sistema de recomendações opere com informações de produto sempre atualizadas. O `Estoque` proporciona controle de quantidade, alertas para estoque abaixo do mínimo e registro de entradas e saídas, uma funcionalidade vital para a gestão de inventário e para evitar rupturas ou excessos de estoque. O módulo de `Vendas` abrange a criação, adição e remoção de itens, confirmação com baixa automática de estoque e cancelamento, automatizando processos operacionais e reduzindo a intervenção manual. As `Recomendações Inteligentes` integram-se ao Recombee para fornecer sugestões personalizadas por cliente, um recurso de inteligência artificial que pode impulsionar as vendas e a satisfação do cliente. Finalmente, os `Relatórios Gerenciais` oferecem um resumo de vendas por período, produtos mais vendidos, clientes que mais compraram e a posição do estoque, fornecendo *insights* estratégicos para a tomada de decisões. A implementação desses módulos demonstra o sucesso em integrar funcionalidades operacionais tradicionais com recursos avançados de inteligência artificial, respondendo à problemática de gestão de vendas e estoque em pequenas empresas.
A interface REST expõe os *endpoints* distribuídos nos módulos, conforme detalhado na Tabela 2. A implementação desses *endpoints* segue as melhores práticas de design de APIs, garantindo uma comunicação eficiente e segura entre o *frontend* e o *backend*.
Tabela 2. Endpoints implementados por módulo
|
Método |
Rota |
Descrição |
|
POST |
/api/auth/login |
Autentica o usuário e retorna um token JWT |
|
POST |
/api/auth/usuarios |
Cria um novo usuário do sistema (apenas Admin) |
|
GET |
/api/clientes |
Lista todos os clientes |
|
GET |
/api/clientes/{id} |
Retorna um cliente pelo ID |
|
GET |
/api/clientes/documento/{documento} |
Busca um cliente pelo CPF ou CNPJ |
|
GET |
/api/clientes/ativos |
Lista apenas os clientes ativos |
|
GET |
/api/clientes/buscar?nome={nome} |
Busca clientes pelo nome |
|
POST |
/api/clientes |
Cadastra um novo cliente |
|
PUT |
/api/clientes/{id} |
Atualiza os dados de um cliente |
|
PATCH |
/api/clientes/{id}/ativar |
Reativa um cliente inativo |
|
PATCH |
/api/clientes/{id}/inativar |
Inativa um cliente ativo |
|
POST |
/api/clientes/{id}/contatos |
Adiciona um contato secundário ao cliente |
|
POST |
/api/clientes/{id}/enderecos |
Adiciona um endereço secundário ao cliente |
|
GET |
/api/produtos |
Lista todos os produtos |
|
GET |
/api/produtos/{id} |
Retorna um produto pelo ID |
|
GET |
/api/produtos/codigo/{codigo} |
Busca um produto pelo código interno |
|
GET |
/api/produtos/ativos |
Lista apenas os produtos ativos |
|
GET |
/api/produtos/categoria/{categoria} |
Lista produtos por categoria |
|
GET |
/api/produtos/buscar?nome={nome} |
Busca produtos pelo nome |
|
POST |
/api/produtos |
Cadastra um novo produto |
|
PUT |
/api/produtos/{id} |
Atualiza os dados de um produto |
|
PATCH |
/api/produtos/{id}/ativar |
Reativa um produto inativo |
|
PATCH |
/api/produtos/{id}/inativar |
Inativa um produto ativo |
|
PATCH |
/api/produtos/{id}/estoque/adicionar |
Adiciona quantidade ao estoque do produto |
|
PATCH |
/api/produtos/{id}/estoque/remover |
Remove quantidade do estoque do produto |
|
GET |
/api/estoque |
Lista o estoque de todos os produtos |
|
GET |
/api/estoque/{id} |
Retorna um registro de estoque pelo ID |
|
GET |
/api/estoque/produto/{produtold} |
Retorna o estoque de um produto específico |
|
GET |
/api/estoque/baixo |
Lista produtos com estoque abaixo do mínimo |
|
GET |
/api/estoque/disponivel/{produtold}/{quantidade} |
Verifica disponibilidade de estoque |
|
POST |
/api/estoque |
Cria o registro de estoque de um produto |
|
PUT |
/api/estoque/{id} |
Atualiza quantidade mínima e localização |
|
POST |
/api/estoque/entrada |
Registra entrada de mercadoria |
|
POST |
/api/estoque/saida |
Registra saída de mercadoria |
|
GET |
/api/vendas |
Lista todas as vendas |
|
GET |
/api/vendas/{id} |
Retorna uma venda pelo ID |
|
GET |
/api/vendas/cliente/{clienteld} |
Lista todas as vendas de um cliente |
|
GET |
/api/vendas/status/{status} |
Filtra vendas por status |
|
GET |
/api/vendas/periodo?dataInicio={data}&dataFim={data} |
Lista vendas por período |
|
GET |
/api/vendas/total?dataInicio={data}&dataFim={data} |
Retorna o valor total de vendas no período |
|
POST |
/api/vendas |
Cria uma nova venda |
|
POST |
/api/vendas/{id}/itens |
Adiciona um item à venda |
|
DELETE |
/api/vendas/{id}/itens/{itemId} |
Remove um item da venda |
|
PATCH |
/api/vendas/{id}/itens/{itemId}/quantidade |
Atualiza a quantidade de um item |
|
POST |
/api/vendas/{id}/confirmar |
Confirma a venda e baixa o estoque |
|
POST |
/api/vendas/{id}/cancelar |
Cancela a venda |
|
GET |
/api/recomendacoes/cliente/{clienteld} |
Retorna produtos recomendados para um cliente |
|
GET |
/api/recomendacoes/cliente/{clienteId}/completo |
Retorna o cliente com suas recomendações |
|
GET |
/api/recomendacoes/todos |
Retorna todos os clientes com suas recomendações |
|
GET |
/api/relatorios/vendas/total-pedidos?dataInicio={data}&dataFim={data} |
Total de pedidos no período |
|
GET |
/api/relatorios/vendas/valor-total?dataInicio={data}&dataFim={data} |
Valor total vendido no período |
|
GET |
/api/relatorios/vendas/ticket-medio?dataInicio={data}&dataFim={data} |
Ticket médio no período |
|
GET |
/api/relatorios/vendas/por-produto?dataInicio={data}&dataFim={data} |
Produtos mais vendidos no período |
|
GET |
/api/relatorios/vendas/por-cliente?dataInicio={data}&dataFim={data} |
Clientes que mais compraram no período |
|
GET |
/api/relatorios/vendas/por-categoria?dataInicio={data}&dataFim={data} |
Categorias mais vendidas no período |
|
GET |
/api/relatorios/estoque |
Posição atual do estoque |
Fonte: Resultados originais da pesquisa
A Tabela 2 detalha os *endpoints* implementados, revelando a granularidade e a organização da API REST. Cada *endpoint* é descrito pelo método HTTP (POST, GET, PUT, PATCH, DELETE), sua rota e uma breve descrição da funcionalidade. Por exemplo, `/api/auth/login` e `/api/auth/usuarios` gerenciam a autenticação e o cadastro de usuários, respectivamente, com o primeiro retornando um token JWT para sessões seguras. Os *endpoints* de `/api/clientes` permitem operações CRUD completas, incluindo busca por ID, documento, nome, status (ativos), e a adição de contatos e endereços secundários, evidenciando a robustez da gestão de clientes. Similarmente, `/api/produtos` oferece funcionalidades para listar, buscar, cadastrar, atualizar e inativar produtos, além de gerenciar o estoque diretamente (`/api/produtos/{id}/estoque/adicionar`, `/api/produtos/{id}/estoque/remover`). Os *endpoints* de `/api/estoque` fornecem visibilidade sobre o inventário, incluindo produtos com estoque baixo e verificação de disponibilidade. O módulo de vendas, acessível via `/api/vendas`, permite a criação, gerenciamento de itens, confirmação e cancelamento de vendas, com a baixa automática de estoque. Os *endpoints* de `/api/recomendacoes` são cruciais para o módulo de inteligência artificial, permitindo a recuperação de sugestões personalizadas para clientes específicos ou todos os clientes. Por fim, `/api/relatorios` oferece *endpoints* para obter dados agregados de vendas (total de pedidos, valor total, ticket médio, produtos mais vendidos, clientes que mais compraram, vendas por categoria) e a posição atual do estoque, fornecendo a base para as visualizações gerenciais. Essa estrutura de *endpoints* demonstra a capacidade do sistema de suportar todas as operações de negócio de forma programática e eficiente, facilitando a integração com o *frontend* e futuras extensões.
O módulo de Vendas merece destaque pela sua integração entre camadas e serviços. Ao confirmar uma venda, o sistema verifica automaticamente a disponibilidade de estoque para cada item, realiza a baixa das quantidades e, em seguida, envia os eventos de compra ao Recombee para alimentar o modelo de recomendações. Essa integração ocorre de forma resiliente, onde uma eventual falha na comunicação com o Recombee não impede a confirmação da venda, garantindo que o sistema central de negócio não seja afetado por dependências externas. Essa abordagem está alinhada aos princípios de tolerância a falhas discutidos por Richards e Ford (2020), que enfatizam a importância de projetar sistemas que possam continuar operando mesmo na presença de falhas parciais. A automação da baixa de estoque e o envio de eventos de compra em tempo real são cruciais para a eficiência operacional e para a acurácia das recomendações, respectivamente.
Da mesma forma, o módulo de Produtos sincroniza automaticamente os dados com o Recombee ao criar ou atualizar um produto. Essa sincronização garante que o catálogo do sistema de recomendações esteja sempre atualizado, sem exigir ação manual do operador. A consistência dos dados entre o sistema de gestão e o serviço de recomendações é vital para a relevância e a qualidade das sugestões oferecidas aos clientes, impactando diretamente a experiência de compra e as taxas de conversão.
A segurança da informação foi tratada com a implementação de autenticação baseada em JSON Web Tokens (JWT), um padrão amplamente adotado em APIs REST modernas por sua natureza *stateless* e compatibilidade com aplicações distribuídas. A comunicação entre o *frontend* e a API ocorre exclusivamente via HTTPS, com os tokens JWT transmitidos no cabeçalho Authorization de cada requisição autenticada. O sistema utiliza o pacote Microsoft.AspNetCore.Authentication.JwtBearer para validação dos tokens e o IPasswordHasher do próprio ecossistema ASP.NET Core para o *hashing* de senhas, com o algoritmo PBKDF2, garantindo segurança adequada sem dependência de bibliotecas externas. Todos os *endpoints*, com exceção do login, exigem um token JWT válido, e o *endpoint* de criação de usuários é restrito à *role* Admin, impedindo que usuários comuns criem novas contas. Um usuário administrador padrão é criado automaticamente na primeira inicialização do sistema, viabilizando o acesso inicial sem necessidade de *scripts* manuais. Os tokens gerados têm validade de 8 horas e incluem as *claims* de identificação, e-mail, nome e *role* do usuário. Essa implementação de segurança é robusta e segue as melhores práticas da indústria, protegendo os dados e o acesso ao sistema.
A estratégia de testes foi estruturada em três níveis complementares, conforme preconizado por Sommerville (2011), para garantir a qualidade do software. Foram realizados testes unitários de domínio, cobrindo entidades e objetos de valor, totalizando 154 testes. Esses testes validaram comportamentos como a criação e imutabilidade dos objetos de valor (CPF, CNPJ, Documento, Contato, Endereço), as transições de estado das entidades (ativação, inativação, confirmação e cancelamento de vendas), as regras de negócio que protegem as invariantes do domínio e os casos de falha esperados. Todos os 154 testes foram aprovados, confirmando a robustez da lógica de negócio.
Adicionalmente, 58 testes unitários de aplicação foram executados para validar os serviços da camada de aplicação, utilizando o *framework* xUnit e a biblioteca Moq para criação de dublês. Os serviços testados foram ClienteService, ProdutoService, EstoqueService, VendaService e RecomendacaoService. Esses testes verificaram cenários como a rejeição de documentos duplicados no cadastro de clientes, a propagação correta de erros de domínio (como estoque insuficiente ao confirmar uma venda), o comportamento frente a falhas na integração com o Recombee e a correta devolução de quantidades ao estoque no cancelamento de uma venda previamente confirmada. Todos os 58 testes foram aprovados, garantindo a integridade e o comportamento esperado dos serviços de aplicação. A distribuição desses testes por serviço é apresentada na Tabela 3.
Tabela 3. Distribuição dos testes unitários por serviço
|
Serviço |
Quantidade de Testes |
|
ClienteService |
11 |
|
ProdutoService |
11 |
|
EstoqueService |
14 |
|
VendaService |
17 |
|
RecomendacaoService |
5 |
|
Total |
58 |
Fonte: Resultados originais da pesquisa
A Tabela 3, que detalha a distribuição dos testes unitários por serviço, oferece uma visão quantitativa da cobertura de testes na camada de aplicação. Observa-se que o `VendaService` possui o maior número de testes (17), o que é esperado, dada a complexidade e a criticidade das operações de venda, que envolvem múltiplas regras de negócio e interações com outras camadas e serviços (como estoque e recomendações). O `EstoqueService` também apresenta um número significativo de testes (14), refletindo a importância do controle de inventário para a operação do negócio. `ClienteService` e `ProdutoService` possuem 11 testes cada, cobrindo as funcionalidades CRUD e validações específicas de cada entidade. O `RecomendacaoService`, com 5 testes, foca na validação da integração com o Recombee e no tratamento de cenários de falha, uma vez que a lógica complexa de recomendação é delegada ao serviço externo. O total de 58 testes unitários na camada de aplicação, somados aos 154 testes de domínio, totalizando 212 testes unitários, demonstra um compromisso com a qualidade do software e a aplicação rigorosa de práticas de engenharia de software, conforme defendido por Sommerville (2011). Essa cobertura abrangente de testes é um resultado crucial para a confiabilidade e a manutenibilidade do sistema Nexsell.
Testes de integração automatizados foram elaborados e executados no projeto Teste.Integration, utilizando o *framework* xUnit, diretamente contra a API do Recombee. A qualidade das recomendações foi mensurada por meio das métricas Precision@K e Recall@K, amplamente reconhecidas na literatura de sistemas de recomendação (Ricci, Rokach e Shapira, 2015). Para cada um dos 55 cenários de avaliação, aplicou-se a técnica de *train/test split*, onde quatro compras foram usadas para treino e duas retidas como *ground truth* para avaliação, com K=5 para as métricas. Essa metodologia permitiu simular o comportamento de clientes reais e avaliar a capacidade do algoritmo de recomendação em diferentes contextos de preferência e histórico de compras.
Os resultados obtidos da integração com o Recombee e a avaliação das recomendações são apresentados na Tabela 4.
Tabela 4. Precision@5 e Recall@5 por perfil de cliente
|
Perfil |
N |
Precision@5 |
Recall@5 |
|
Esportista |
11 |
34,50% |
86,4% |
|
Gamer |
11 |
12,70% |
31,8% |
|
HomeOffice |
11 |
7,3% |
18,2% |
|
Leitor |
11 |
34,5% |
86,4% |
|
Programador |
11 |
7,3% |
18,2% |
Fonte: Resultados originais da pesquisa
A Tabela 4 apresenta os resultados das métricas Precision@5 e Recall@5 para cada um dos cinco perfis de cliente simulados, além de um total geral. Esses dados são fundamentais para compreender o desempenho do sistema de recomendações em diferentes contextos de consumo. O perfil `Esportista` e `Leitor` demonstraram os melhores resultados, com Precision@5 de 34,5% e Recall@5 de 86,4%. Esses valores são notavelmente próximos ao teto teórico de 40% para Precision@5 e 100% para Recall@5 no cenário avaliado (com 2 itens de *ground truth* e K=5), indicando uma alta assertividade do algoritmo para perfis com comportamento de compra homogêneo dentro de uma única categoria. Esse achado corrobora a literatura que aponta a eficácia da filtragem colaborativa em identificar padrões de similaridade entre usuários com preferências bem definidas (Ricci, Rokach e Shapira, 2015).
Em contraste, os perfis `Programador` e `HomeOffice` registraram os menores desempenhos, com Precision@5 de 7,3% e Recall@5 de 18,2%. Essa diferença significativa é explicada pelo comportamento de compra heterogêneo desses perfis, onde os itens de *ground truth* pertenciam a categorias distintas. Algoritmos de filtragem colaborativa, embora poderosos, tendem a ter maior dificuldade em acertar recomendações quando os interesses do usuário são muito diversificados ou distribuídos por categorias pouco relacionadas, como observado por Ricci, Rokach e Shapira (2015). Nesses casos, o algoritmo pode tender a se concentrar em uma das categorias, recuperando apenas um dos itens relevantes na maioria dos cenários.
O perfil `Gamer` apresentou um desempenho intermediário, com Precision@5 de 12,7% e Recall@5 de 31,8%. Esse resultado pode ser atribuído à sobreposição de duas categorias (Informática e Eletrônicos) no histórico de compras, o que, embora menos homogêneo que os perfis `Leitor` e `Esportista`, é menos disperso que os perfis `Programador` e `HomeOffice`. O algoritmo demonstrou maior assertividade nos itens de Informática do que nos itens de Eletrônicos para esse perfil, resultando em acertos parciais na maioria dos cenários.
A média geral de Precision@5 de 19,3% e Recall@5 de 48,2% posiciona o sistema dentro da faixa de desempenho esperada para a configuração de dados utilizada e para catálogos de pequeno porte. Esses resultados demonstram que o sistema de recomendação, mesmo com dados sintéticos, é capaz de gerar sugestões relevantes, com desempenho variando conforme a complexidade dos padrões de consumo. A Figura 3 apresenta esses mesmos resultados em formato gráfico, facilitando a comparação visual entre os perfis.

Figura 3. Comparativo de Precision@5 e Recall@5 por perfil de cliente nos 55 cenários de teste de integração com o Recombee
Fonte: Resultados originais da pesquisa
A Figura 3 oferece uma representação visual clara e concisa dos resultados apresentados na Tabela 4, permitindo uma rápida comparação do desempenho das métricas Precision@5 e Recall@5 entre os diferentes perfis de clientes. O gráfico de barras horizontais destaca visualmente a superioridade dos perfis `Esportista` e `Leitor` em ambas as métricas, com as barras de Precision@5 e Recall@5 atingindo comprimentos significativamente maiores em comparação com os outros perfis. Essa visualização reforça a conclusão de que a homogeneidade do comportamento de compra do cliente impacta diretamente a eficácia do sistema de recomendação. Os perfis `Gamer` mostram um desempenho intermediário, com barras de comprimento moderado, enquanto `HomeOffice` e `Programador` exibem as menores barras, ilustrando graficamente a dificuldade do algoritmo em lidar com interesses mais heterogêneos. A representação gráfica facilita a identificação dos pontos fortes e fracos do sistema de recomendação em diferentes cenários, sendo uma ferramenta valiosa para a interpretação dos resultados e para a comunicação das descobertas. A clareza visual é essencial para que gestores e desenvolvedores compreendam rapidamente onde o sistema performa melhor e onde há espaço para otimização, por exemplo, através de estratégias de diversificação de recomendações para perfis com interesses amplos.
A execução automatizada dos 55 cenários de teste com o cálculo das métricas por perfil pode ser verificada na Figura 4, que mostra a saída do teste de integração.
Figura 4. Saída do teste de integração exibindo as métricas Precision@5 e Recall@5 calculadas para os 55 cenários avaliados por perfil de cliente
Fonte: Resultados originais da pesquisa
A Figura 4 apresenta a saída textual do teste de integração, que valida o processo de sincronização de dados com o Recombee e a avaliação das recomendações. A sequência de mensagens “[0/4] Garantindo schema de propriedades no Recombee… OK Schema verificado (nome, categoria, preco).”, “[1/4] Registrando produtos no Recombee (sequencial)… OK 50 produtos registrados.”, “[2/4] Enviando interações de treino (sequencial)… OK 220 interações (55 clientes × 4 compras).”, “[3/4] Aguardando processamento do Recombee (3 s)…”, e “[4/4] Obtendo e avaliando recomendações… OK 55 cenários avaliados.” demonstra o fluxo completo e bem-sucedido da execução dos testes. Essa saída confirma que o sistema realizou todas as etapas necessárias para a validação do módulo de recomendações, desde a verificação do esquema de dados até o registro de produtos, o envio de interações de treino e, finalmente, a obtenção e avaliação das recomendações para todos os 55 cenários. A seção “MÉTRICAS POR PERFIL” na Figura 4 replica os dados da Tabela 4, fornecendo uma prova direta da computação dessas métricas durante a execução do teste. A linha “TOTAL 55 19,3% 48,2%” resume o desempenho geral, corroborando os resultados agregados. Essa evidência da execução automatizada dos testes é crucial para a credibilidade dos resultados, pois mostra que o processo de avaliação é replicável e consistente, um pilar da engenharia de software moderna (Sommerville, 2011).
A validação dos limiares mínimos estabelecidos (Precision@5 ≥ 5% e Recall@5 ≥ 10%), confirmada pelo *framework* xUnit, é apresentada na Figura 5.
Figura 5. Resultado final da execução dos testes de integração, confirmando aprovação nos limiares mínimos estabelecidos
Fonte: Resultados originais da pesquisa
A Figura 5 exibe o resultado final da execução dos testes de integração, fornecendo uma confirmação explícita de que o sistema atendeu aos critérios mínimos de desempenho estabelecidos. A mensagem “Execução de Teste Bem-sucedida. Total de testes: 1 Aprovados: 1 Tempo total: 1,2245 Minutos Teste.Integration teste net8.0 êxito (74,4s)” indica que o teste de integração principal foi concluído com sucesso, sem falhas. A linha “Resumo do teste: total: 1; falhou: 0; bem-sucedido: 1; ignorado: 0; duração: 74,3s” reforça a aprovação total. Essa validação formal, realizada por um *framework* de testes, é um resultado crítico que atesta a funcionalidade e a qualidade do módulo de recomendações. A aprovação nos limiares mínimos de Precision@5 (≥ 5%) e Recall@5 (≥ 10%) demonstra que o sistema é capaz de gerar recomendações com um nível aceitável de relevância, mesmo nos cenários mais desafiadores. Embora os limiares sejam relativamente baixos, eles servem como uma base para garantir que o algoritmo esteja funcionando corretamente e que a integração técnica com o Recombee foi bem-sucedida. Para pequenas empresas, ter um sistema que gera recomendações, mesmo que com desempenho variável, já representa um avanço significativo em relação à ausência de tal funcionalidade, abrindo portas para a personalização da experiência do cliente e o potencial aumento de vendas.
Os resultados demonstram um desempenho satisfatório para sistemas de recomendação aplicados a catálogos de pequeno porte. Ricci, Rokach e Shapira (2015) destacam que o desempenho de sistemas de recomendação varia significativamente conforme o volume de interações disponíveis por usuário, o que explica a diferença de desempenho observada entre os perfis avaliados. Os perfis com comportamento homogêneo (Leitor e Esportista) atingiram Precision@5 de 34,5% e Recall@5 de 86,4%, valores próximos ao teto teórico de 40% para o cenário avaliado. Nesses casos, o algoritmo de filtragem colaborativa identificou com precisão a similaridade entre os usuários e concentrou as recomendações nos itens corretos. Na maioria dos cenários desses perfis, ambos os itens de *ground truth* foram recuperados entre as cinco primeiras sugestões, atingindo Recall@5 = 100% individualmente. Isso sugere que para empresas com um nicho de mercado bem definido ou clientes com padrões de compra consistentes, o sistema Nexsell pode oferecer recomendações altamente eficazes, impulsionando a venda cruzada e a satisfação do cliente.
O perfil Gamer obteve Recall@5 de 31,8%, um desempenho intermediário explicado pela sobreposição de duas categorias no histórico de compras. O algoritmo demonstrou maior assertividade nos itens de Informática do que nos itens de Eletrônicos, resultando em acertos parciais na maioria dos cenários. Isso indica que, para clientes com interesses em categorias adjacentes, o sistema ainda consegue gerar recomendações relevantes, mas com uma precisão um pouco menor. Para otimizar o desempenho nesses casos, futuras melhorias poderiam explorar a ponderação de categorias ou a incorporação de mais atributos de item para refinar a filtragem baseada em conteúdo.
Os perfis Programador e HomeOffice registraram o menor Recall@5 (18,2% cada). Nesses perfis, os dois itens de *ground truth* pertenciam a categorias distintas, exigindo que o sistema acertasse em ambas simultaneamente. As recomendações do Recombee tenderam a se concentrar em uma das categorias, recuperando apenas um dos dois itens relevantes na maioria dos casos. Esse comportamento é consistente com a literatura, que indica maior dificuldade para algoritmos de filtragem colaborativa quando o usuário possui interesses heterogêneos entre categorias pouco relacionadas (Ricci, Rokach e Shapira, 2015). Para empresas com clientes de interesses muito diversificados, a implicação prática é que o sistema pode precisar de mais dados de interação ou de estratégias de recomendação híbridas para melhorar a diversidade e a relevância das sugestões. A média geral de Precision@5 de 19,3% e Recall@5 de 48,2% posiciona o sistema dentro da faixa de desempenho esperada para a configuração de dados utilizada, confirmando a viabilidade da solução para catálogos de pequeno porte.
Além dos testes automatizados, o módulo de recomendações foi validado funcionalmente por meio do *endpoint* GET `/api/recomendacoes/cliente/{clienteId}/completo` da API REST. Esse *endpoint* retorna os produtos recomendados enriquecidos com os dados cadastrais do sistema, incluindo nome do produto, categoria e preço unitário. A resposta do *endpoint* para um cliente específico, conforme ilustrado na Figura 6, confirma que o fluxo completo de integração está operacional: as compras registradas no sistema são automaticamente enviadas ao Recombee, que processa o histórico e devolve sugestões personalizadas em tempo real.
Figura 6. Resposta do endpoint de recomendações da API REST retornando produtos personalizados para um cliente com base em seu histórico de compras.
Fonte: Resultados originais da pesquisa.
A Figura 6 exibe a resposta JSON do *endpoint* `/api/recomendacoes/cliente/{clienteId}/completo`, demonstrando a validação funcional do módulo de recomendações inteligentes. O corpo da resposta mostra uma lista de objetos JSON sob a chave “recomendacoes”, onde cada objeto representa um produto sugerido. Para cada produto, são retornados o `produtoId`, `produtoNome`, `categoria` e `precoUnitario`. Por exemplo, a primeira recomendação é um “Mouse Wireless Logitech MX Master” da categoria “Perifericos” com preço unitário de 599.9. Outras recomendações incluem um “Notebook Dell XPS” da categoria “Informatica” e um “Teclado Mecanico Logitech” também de “Perifericos”. Essa estrutura de dados enriquecida é crucial para o *frontend*, pois permite exibir as recomendações de forma completa e útil para o cliente, sem a necessidade de realizar chamadas adicionais ao *backend* para obter detalhes do produto. A presença de diferentes categorias nas recomendações (Periféricos, Informática) sugere que o algoritmo está considerando uma variedade de produtos, embora a diversificação possa ser um desafio para perfis heterogêneos, como discutido anteriormente. A validação funcional do *endpoint* é um resultado prático que confirma a capacidade do sistema de entregar sugestões personalizadas em tempo real, um recurso de inteligência artificial que pode transformar a experiência de compra em pequenas empresas, tornando-as mais competitivas ao oferecer um serviço similar ao de grandes *e-commerces*.
Em suma, o sistema Nexsell representa uma solução tecnológica que integra controle operacional e inteligência de dados de forma acessível para pequenas empresas. A adoção de princípios de Domain-Driven Design e Clean Architecture, juntamente com uma estratégia de testes abrangente, garantiu a construção de um sistema robusto, manutenível e extensível. A integração com serviços externos como ViaCEP e Recombee demonstrou a capacidade do sistema de alavancar tecnologias avançadas sem incorrer na complexidade de desenvolvê-las do zero. Os resultados da avaliação do módulo de recomendações, embora com dados sintéticos, confirmaram a eficácia do algoritmo em identificar padrões de consumo e gerar sugestões relevantes, especialmente para perfis de clientes com interesses homogêneos. A resiliência frente a falhas externas, garantida pelo isolamento das integrações, é um resultado arquitetural crucial que protege as operações centrais do negócio.
A principal limitação metodológica identificada foi a utilização de dados sintéticos para a avaliação das recomendações. Embora essa abordagem tenha sido suficiente para validar a integração técnica e o funcionamento do algoritmo, ela não substitui uma avaliação com dados reais de operação em um ambiente de produção. Dados reais poderiam oferecer *insights* adicionais sobre o desempenho em condições de uso real, incluindo a interação dos usuários com as recomendações e o impacto nas métricas de negócio. Como trabalhos futuros, sugere-se a validação do sistema com dados reais de operação em ambiente de produção, a expansão do módulo de relatórios com indicadores de desempenho das recomendações (por exemplo, taxa de cliques, taxa de conversão das recomendações) e a avaliação do impacto das sugestões no comportamento de compra dos clientes ao longo do tempo. Essas etapas futuras seriam cruciais para refinar o sistema e maximizar seu valor para as pequenas e médias empresas.
4. Conclusão
Conclui-se que o objetivo foi atingido, apresentando o desenvolvimento do Nexsell, um sistema inteligente de gestão de vendas que integra funcionalidades operacionais tradicionais com recursos de recomendações personalizadas. A solução demonstrou ser acessível e robusta, otimizando as operações e aprimorando a experiência do cliente em pequenas e médias empresas por meio de sugestões baseadas em seu histórico de compras. A arquitetura adotada, baseada em Domain-Driven Design e Clean Architecture, garantiu a construção de um sistema manutenível, extensível e resiliente, com integrações bem-sucedidas a serviços externos como ViaCEP e Recombee. Os testes automatizados confirmaram a robustez da lógica de negócio e a eficácia da integração. O módulo de recomendações, mesmo com dados sintéticos, apresentou uma Precision@5 média de 19,3% e Recall@5 de 48,2%, com desempenho superior para perfis de clientes com comportamento de compra homogêneo, validando a capacidade do sistema em gerar sugestões relevantes e impulsionar vendas.
A principal limitação metodológica deste trabalho reside na utilização de dados sintéticos para a avaliação das recomendações. Embora essa abordagem tenha sido crucial para validar a integração técnica e o funcionamento do algoritmo, ela não reflete plenamente o desempenho em um ambiente de produção com dados reais, o que poderia oferecer *insights* mais aprofundados sobre a interação dos usuários e o impacto nas métricas de negócio. Como estudos futuros, sugere-se a validação do sistema com dados reais de operação, a expansão do módulo de relatórios para incluir indicadores de desempenho das recomendações, como taxa de cliques e conversão, e a avaliação do impacto das sugestões no comportamento de compra dos clientes ao longo do tempo. Essas próximas etapas são essenciais para o aprimoramento contínuo do Nexsell e a maximização de seu valor para o mercado.
Referências Bibliográficas
EVANS, E. Domain-Driven Design: Tackling Complexity in the Heart of Software. Boston: Addison-Wesley, 2003.
GIL, A. C. Como elaborar projetos de pesquisa. 4. ed. São Paulo: Atlas, 2002.
LAUDON, K. C.; LAUDON, J. P. Sistemas de Informação Gerenciais: Administrando a Empresa Digital. 17. ed. São Paulo: Pearson; Porto Alegre: Bookman, 2023.
OPENAPI INITIATIVE. A Short History of the OpenAPI Initiative and the OpenAPI Specification. 2015. Disponível em: https://www.openapis
RICCI, F.; ROKACH, L.; SHAPIRA, B. Recommender Systems Handbook. 2. ed. New York: Springer, 2015.
RICHARDS, M.; FORD, N. Fundamentos de Arquitetura de Software: Uma Abordagem de Engenharia. São Paulo: Novatec Editora, 2020.
SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall, 2011.
VERNON, V. Implementing Domain-Driven Design. Boston: Addison-Wesley, 2013.
Artigo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq
Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy

