Em Um Sistema De Gerenciamento De Biblioteca Desenvolvido Em Java

Construindo um sistema de gerenciamento de biblioteca em Java

A maior parte dos tutoriais que você vai encontrar pela internet começa empolgada com Spring Boot e banco de dados relacional. A realidade é mais chata. Você precisa lidar com cadastros de usuários, empréstimos, devoluções, multas por atraso e, eventualmente, uma fila de espera quando o exemplar está emprestado. Se você não planejar essas relações desde o início, o sistema vira um monte de tabelas desconectadas que ninguém consegue manter. Eu comecei vários projetos desses na vida e a maioria deles parou por algum motivo óbvio. O problema real não é fazer funcionar — é fazer funcionar quando alguém começa a cadastrar livros de verdade, com ISBNs duplicados, autores com nomes estranhos e edições diferentes do mesmo título. Eu cheguei a perder dois meses refazendo o módulo de pesquisa porque não havia indexação própria e as queries ficavam travando o banco depois de umas 15 mil entradas.

em um sistema de gerenciamento de biblioteca desenvolvido em java

Vamos direto para o que importa. A arquitetura básica que costuma funcionar — e se sustentar — tem três camadas: apresentação, negócio e acesso a dados. Não adianta juntar tudo em uma única classe main só porque o trabalho é pequeno. O primeiro dia de uso real mostra onde cada pedaço deveria estar, mas você já terá que refatorar se quiser evoluir o projeto. No lado técnico, o caminho mais direto passa por usar Spring Data JPA com PostgreSQL. Funciona bem o tempo todo. O H2 é útil só para desenvolvimento rápido, mas não vá para produção com ele achando que é alternativa viável. O PostgreSQL suportafts_vector nativamente, o que faz diferença quando você precisa fazer busca por título ou autor sem depender de LIKE com curingões. O modelo central do sistema gira em torno de quatro entidades principais: Livro, Autor, Empréstimo e Usuário. A relação entre Livro e Autor é muitos-para-muitos porque um livro pode ter vários autores e um autor pode ter vários livros. Muita gente erra aqui e cria uma tabela intermediária manualmente quando o JPA resolve isso com @ManyToMany em menos de cinco linhas. O problema é que essa entidade intermediária inevitavelmente ganha campos depois, como data de inclusão ou tipo de contribuição (autor principal versus coautor), e aí o ManyToMany puro vira dor de cabeça.

A solução que eu adotei foi transformar essa relação em uma entidade própria chamada LivroAutor, com seus próprios campos e relacionamentos muitos-para-um para Livro e Autor separadamente. Dá um pouco mais de código inicial, mas evita migrações dolorosas depois. Vale cada linha extra.

Implementando o controle de empréstimos

O módulo de empréstimo é onde o sistema mostra se foi bem pensado ou se foi jogado together na pressa. Um empréstimo precisa responder perguntas simples na prática: quem pegou, qual livro, quando começou, quando deve voltar e se voltou no prazo. O campo mais criticado por quem vai usar o sistema no dia a dia é a data de devolução prevista. Ela precisa ser calculada automaticamente com base no tipo de usuário — estudante de graduação pega por 30 dias, pós-graduação por 60, professor por 90. Isso parece simples até você precisar lidar com feriados e finais de semana. O Java 8 trouxe a classe Period e o método plusDays(), mas eles não ignoram feriados. Para um sistema real, eu implantei uma lista de feriados nacionais e estaduais carregada de um arquivo properties no classpath, e um método que avança a data pulando os dias que caem nos feriados cadastrados. O cálculo de multa também costuma ser subestimado. A multa por dia de atraso varia conforme a categoria do livro. Livros de referência não saem da biblioteca, então a multa não se aplica. Livros comuns cobram um valor fixo diário. Já livros raros ou restritos têm multa progressiva que dobra a cada sete dias de atraso. Esse tipo de regra precisa viver na camada de serviço, nunca no controller ou na entidade. Se você colocar lógica de negócio na entidade, o código fica ilegível em poucas semanas.

Um problema específico que eu enfrentei foi a situação em que o mesmo exemplar de um livro tinha dois empréstimos ativos ao mesmo tempo por causa de uma falha de sincronização na interface. Dois funcionários estavam atendendo no mesmo computador e um deles registrou a devolução enquanto o outro ainda estava finalizando o empréstimo anterior. O resultado foi um empréstimo órfão que nunca foi fechado e uma multa registrada para um usuário que já tinha devolvido o livro há três dias. O workaround que eu apliquei foi implementar um bloqueio otimista com versionamento na entidade Empréstimo. Cada transação de devolução ou prorrogação incrementa um campo version, e se o valor não corresponder ao estado atual do banco, a operação é rejeitada com uma exceção controlada que a interface trata mostrando uma mensagem clara para o funcionário tentar novamente. Não é elegante, mas evita inconsistências silenciosas que aparecem meses depois quando alguém vai fechar o caixa.

Estrutura de dados e integrações

O cadastro de livros precisa aceitar ISBN-10 e ISBN-13. A validação básica é fácil, mas a validação do dígito verificador merece atenção. O algoritmo para ISBN-10 usa pesos de 10 a 1 descendentes e o último dígito pode ser X. Para ISBN-13, os pesos alternam entre 1 e 3. Se você não validar esses dígitos, vai ter cadastro duplicado por erro de digitação com frequência suficiente para entupir a base de dados. A integração com API externa de metadados de livros também é parte importante do fluxo. Eu usei a API da Google Books para preenchimento automático de título, autor, editorial e capa quando o funcionário digita o ISBN. A API é gratuita e não exige autenticação para uso moderado. O problema é que ela retorna dados inconsistentes em alguns casos, especialmente para livros antigos ou publicações independentes. Eu implementei um cache local com expiration de 30 dias usando um ConcurrentHashMap simples, porque chamar a API toda vez que um ISBN for cadastrado é lento e desnecessário. O sistema também precisa lidar com cópias físicas. Um mesmo título pode ter dezenas de exemplares na prateleira, cada um com um código de patrimônio único. A entidade Cópia é onde isso vive. Cada cópia tem um status: disponível, emprestado, em reparo, extraviado ou baixado. A baixa é o procedimento que retira definitivamente o exemplar do acervo, seja por perda, deterioração ou doação. Esse campo costuma ser esquecido em projetos iniciantes, mas aparece na primeira auditoria como algo que precisaria ter existido desde o começo.

Persistência e migrações

Para migrações de schema, o Flyway é a opção mais direta. Ele executa arquivos SQL em ordem cronológica e mantém um registro das versões já aplicadas no banco. Funciona bem desde que você não precise desfazer uma migração que já foi para produção. Desfazer migração no Flyway exige criar um arquivo Vn__undo.sql, o que é trabalhoso e propenso a erro se as tabelas tiverem dependências entre si. Uma alternativa que considerei foi o Liquibase, que gera DML de undo automaticamente em muitos casos. Ele é mais pesado e a curva de aprendizado é maior. Para um sistema de biblioteca de porte médio, o Flyway com migrações manuais bem escritas é suficiente. A chave é nunca modificar uma migração já aplicada. Se algo estiver errado, crie uma nova migração que corrija os dados, em vez de alterar o arquivo original. Os índices no banco precisam ser planejados com antecedência. As queries mais frequentes são: listar livros por autor, listar livros por título com paginação, buscar cópias disponíveis de um ISBN e consultar empréstimos ativos de um usuário. Cada uma dessas operações se beneficia de um índice específico. Sem índice, a busca por título com LIKE '%termo%' escaneia a tabela inteira. Com 50 mil registros, isso começa a levar segundos. Com índice de texto completo via pg_trgm, o mesmo comando volta em milissegundos.

Segurança e controle de acesso

A camada de segurança deve proteger rotas por perfil de usuário. No mínimo, você precisa de três perfis: administrador, bibliotecário e leitor. O administrador configura o sistema. O bibliotecário faz empréstimos, devoluções e cadastros. O leitor consulta o catálogo e visualiza seu histórico pessoal. O Spring Security resolve isso de forma limpa com configuração baseada em roles. O ponto de atenção é a proteção contra CSRF em requests AJAX, porque a interface de empréstimo faz requisições assíncronas o tempo todo. Desabilitar CSRF globalmente é uma má prática. O correto é desabilitar por endpoint ou configurar o token corretamente nos formulários e nas requisições fetch da interface. A senha dos usuários deve ser armazenada com BCrypt. Nada de MD5, nada de SHA-256 sem salt. O BCrypt é lento propositalmente, o que dificulta ataques de força bruta. O custo padrão do Spring Security é 10, o que é adequado para a maioria dos casos. Se o sistema tiver milhares de autenticações por minuto, aumentar para 12 reduz o risco sem impacto perceptível na experiência do usuário.

Testes e manutenção

Sistemas de biblioteca têm regras de negócio que não podem falhar em produção. Um empréstimo registrado duplo ou uma multa calculada errada gera reclamações diretas dos usuários. Testes unitários na camada de serviço e testes de integração na camada de repositório cobrem a maior parte dos cenários críticos. Testes de unidade isolados com Mockito para a lógica de multa e cálculo de prazos levam cerca de uma hora para cobrir os casos principais. Testes de integração com banco real adicionam tempo, mas capturam problemas que o mock nunca mostra. O deploy deve ser feito com um container Docker que inclua a aplicação e o banco. Isso elimina a diferença entre o ambiente de desenvolvimento e o de produção, que é uma das causas mais comuns de bugs que só aparecem depois que o sistema está no ar. Um arquivo docker-compose simples com dois serviços — app e postgres — resolve a maioria dos problemas de configuração no início do projeto. A documentação do sistema precisa cobrir três coisas: fluxo de empréstimo e devolução, fluxo de cadastro de livros com ISBN e múltiplos autores, e procedimento de baixa de exemplares. Sem isso, qualquer pessoa que assumir a manutenção depois de você vai passar dias decifrando o código. Comentários no código ajudam, mas um manual operacional separado é mais eficiente para quem vai usar o sistema no dia a dia.

Limitações e alternativas

Este tipo de sistema não escala bem se você prever mais de cem mil livros no acervo e milhões de transações por ano. A arquitetura descrita aqui funciona para bibliotecas universitárias médias, bibliotecas públicas de porte regional e acervos privados. Se o cenário for maior, a abordagem precisa mudar: banco distribuído, fila de processamento assíncrono para empréstimos, e uma interface separada da camada de persistência. Uma alternativa moderna seria construir a camada de dados com GraphQL em vez de REST puro. Isso reduz over-fetching e under-fetching na interface, especialmente no catálogo de buscas, onde o usuário pode querer filtrar por autor, ano, editora e disponibilidade ao mesmo tempo. Cada campo extra significa um parâmetro a mais na query, e com REST isso tende a gerar endpoints inchados rapidamente. GraphQL centraliza isso em um único endpoint com schema tipado. O downside de GraphQL é a curva de aprendizado da equipe e a complexidade adicional no caching. Se a equipe já domina Spring e REST, forçar GraphQL só por modernidade não justifica o custo. Use quando o catálogo tiver mais de cinco filtros combinatórios consistentemente usados. Caso contrário, REST com filtros bem estruturados basta.

Outro ponto fraco dessa abordagem é a falta de um módulo de análise e relatórios embutido. Bibliotecas precisam gerar relatórios mensais de circulação, livros mais emprestados, usuarios inadimplentes e taxa de retorno no prazo. Esse módulo precisa ser construído separadamente, preferencialmente como uma view materializada no banco que é refrescada periodicamente, em vez de consultas pesadas geradas sob demanda. Consultas analíticas em tempo real sobre tabelas de empréstimo com anos de histórico travam a interface e competem com as operações do dia a dia pelo mesmo pool de conexões. O código-fonte completo, incluindo as entidades, repositórios, serviços e configurações de segurança, está disponível no repositório do projeto. A versão atual inclui a entidade LivroAutor com campos adicionais, o validador de ISBN completo, o cálculo de prazos com feriados e o bloqueio otimista em empréstimos. A branch principal segue a estrutura descrita acima. Dependências principais: Spring Boot 3.2, Spring Data JPA, Spring Security, PostgreSQL 15, Flyway e Docker Compose. Se você está começando agora, não tente incluir tudo de uma vez. Comece com cadastro de livros, cadastro de cópias e empréstimo básico. Só depois disso adicione multa, busca avançada e relatórios. Tentar fazer tudo no primeiro ciclo resulta em código instável que ninguém consegue manter.