pratikchandorkar/library-management

This repository is a classic layered Spring Boot monolith for a library management system. The main architectural boundary is:

HTTP controllers → business services → Spring Data JPA repositories → MySQL database, with Thymeleaf rendering server-side pages back to the browser.

1. Core runtime and framework

The app runs as a Java 17+ Spring Boot application (LibraryManagementApplication). It uses Spring MVC for routing, Spring Data JPA/Hibernate for persistence, Spring Security for login/session protection, and Thymeleaf for server-rendered UI pages.

2. Domain model

The main persisted concepts are:

• Book — catalog item and issue status

• Student — library user/member record

• IssueRecord — links a book to a student, tracks issue/return dates and status

• User — authentication account for application access

These entities define the app’s functional data model and likely map directly to MySQL tables as described in the README.

3. Controller layer

There are two controller entry points:

• AuthController handles login/registration/auth-related pages and submissions

• MainController handles the library workflow pages such as dashboard, books, students, issue, and return screens

Controllers are thin request/response adapters; they prepare model data for Thymeleaf templates and delegate all state changes to services.

4. Service layer

Business logic is concentrated in:

• BookService for book creation, listing, search, deletion, and status updates

• IssueService for issuing and returning books, and likely calculating overdue fines

• UserService for registration and authentication-related user operations

This layer is where domain rules live, such as preventing re-issuing an already issued book or marking a return and updating the corresponding records.

5. Repository layer

Persistence is isolated in:

• BookRepository

• StudentRepository

• IssueRecordRepository

• UserRepository

These are the database access boundary. The application likely relies on Spring Data query methods rather than hand-written SQL, which keeps data access simple and tightly aligned to the entity model.

6. Security architecture

SecurityConfig indicates a session-based Spring Security setup. The README states authentication and authorization are enabled, with BCrypt password encryption. That means:

• unauthenticated users are redirected to login

• protected pages require a valid session

• credentials are stored hashed, not plaintext

• the User entity and UserService are part of the auth flow

The default admin account mentioned in the README is probably created at startup or via seed data.

7. Startup data seeding

DataInitializer suggests the application preloads data on startup. In architecture terms, this is an initialization path separate from normal user-driven flows. It likely creates the default admin account and may optionally add sample records so the UI is usable immediately after first launch.

8. Presentation layer

The UI is server-rendered with Thymeleaf templates under src/main/resources/templates:

• index.html dashboard

• books.html, add-book.html

• students.html, add-student.html

• issue-book.html, return-book.html

• login.html, register.html

Static CSS and JS live under src/main/resources/static. This is a form-driven CRUD interface, not a SPA.

9. Key business flows

The important end-to-end flows are:

• Book management: browser form → controller → BookService → BookRepository → MySQL → updated list view

• Student management: browser form → controller → StudentRepository

• Issue book: select book and student → IssueService creates IssueRecord, marks book as issued

• Return book: select issued record/book → IssueService closes the record, updates book availability, and computes any fine

10. Data consistency boundaries

The IssueRecord table is the transactional record of lending activity. It acts as the bridge between books and students and is the source of truth for whether a book is currently checked out. This is the most important domain boundary in the system because it coordinates state across multiple tables.

11. Database and deployment assumptions

The README configures MySQL as the backing store and uses spring.jpa.hibernate.ddl-auto=update, so schema evolution is handled automatically at startup. The app runs on port 8080 by default and is built with Maven. This is a single-process, database-backed deployment model.

12. What to show in an architecture diagram

A clear diagram should show:

• Browser users accessing Thymeleaf pages through Spring MVC

• Security intercepting requests before protected controllers

• Controllers calling service classes

• Services reading/writing via repositories

• Repositories persisting Book, Student, IssueRecord, and User to MySQL

• Startup initializer seeding initial data

• Static CSS/JS supporting the rendered pages

13. Scale and separation

This is not a microservices system; it is a single deployable application with clean internal layering. The architecture is intentionally simple: presentation, business logic, persistence, and security are separated, but all live in one Spring Boot codebase.