# Repository Overview

Welcome! This repository appears to be a small console-based library management application built around a simple domain model, in-memory repositories, and a service layer that coordinates borrowing and returning books. It uses plain Java rather than a large framework, which makes the code easy to follow from the entry point down to the data objects. If you are new here, think of it as a tidy example of layered application design: UI at the edge, services in the middle, and domain objects plus repositories underneath. The code is compact, so a new contributor should be able to trace a full user flow in just a few files.

## Overview

This project appears to manage a small library workflow: adding books, registering members, borrowing books, returning them, and listing active records. The structure is intentionally straightforward, with a console UI driving the interaction and services handling the application rules. Data is kept in memory through repository classes, so the application seems geared toward simple local use, demos, or exercises rather than long-term persistence.

The main flow seems to be:

1. The console UI collects user input.
2. Service classes validate the request and create or update domain objects.
3. Repository classes store and query books and members in memory.
4. Model objects represent books, members, and loans, including availability and return state.

## Technology Stack

The detected stack appears to be:

- **Java** — the codebase is organized as a standard Java application.
- **Java standard library collections** — used for in-memory lists and query helpers.
- **`java.time.LocalDate`** — used to record borrow and return dates.
- **`java.util.UUID`** — used for generating short, human-readable IDs.
- **`java.util.Scanner`** — used for console input handling.
- **Console I/O** — the UI is built around terminal prompts and printed output.

No well-known application framework was detected from the indexed imports.

## Architecture

This repository appears to follow a classic layered design. The UI layer depends on the service layer, the service layer depends on the repositories and domain model, and the repositories depend on the model objects they store. A small utility module supports the console experience by handling user input.

```mermaid
flowchart TD
Overview["Overview"] --> Model["model package"]
Overview --> Repository["repository package"]
Overview --> Service["service package"]
Overview --> Ui["ui package"]
Overview --> Util["util package"]
Service --> Repository
Service --> Model
Ui --> Service
Ui --> Util
Repository --> Model
Util --> Ui
```

At a high level, the dependency direction appears to be:

- `ui` calls into `service`
- `service` coordinates `repository` and `model`
- `repository` stores `model` objects in memory
- `util` supports `ui` with input helpers

## Module Guide

### `model`

The `model` package appears to contain the core domain objects for the application: `Book`, `Member`, and `Loan`. `Book` stores catalog information and availability, `Member` stores borrower identity details, and `Loan` links a book to a member while tracking borrow and return dates. These classes are lightweight and mostly act as data holders with a little state behavior where needed, especially around loan completion and book availability.

### `repository`

The `repository` package appears to provide in-memory persistence for books and members. `BookRepository` stores `Book` objects and supports lookup, listing, availability filtering, and title search. `MemberRepository` stores `Member` objects and supports lookup and listing. These repositories hide the underlying lists so the rest of the code can work with a small query API rather than managing collection state directly.

### `service`

The `service` package appears to contain the application logic. `LibraryService` handles catalog and member registration tasks, including creating new `Book` and `Member` instances with generated IDs. `LoanService` handles borrow and return operations, validates that books and members exist, updates availability, and keeps active loans in memory. This layer seems to be where the main business rules live.

### `ui`

The `ui` package appears to hold the console entry point. `ConsoleUI` runs the menu loop, reads input, and prints results for the user. It delegates all actual work to the service layer instead of manipulating repositories or model objects directly. That makes it the boundary between the human-facing terminal experience and the application core.

### `util`

The `util` package appears to contain small shared helpers, currently centered on `InputUtils`. That class wraps a shared `Scanner` and provides methods for reading trimmed text, validating integers, and closing the input stream when the app exits. It keeps console parsing concerns in one place so the UI code stays simple.

## Getting Started

If you are new to the repository, a good reading order appears to be:

1. **`Main.java`** — start here to find the application entry point and understand how the UI is launched.
2. **`ui/ConsoleUI.java`** — this shows the user-facing menu flow and reveals which actions the app supports.
3. **`service/LibraryService.java`** and **`service/LoanService.java`** — these explain the real application behavior and how borrowing works.
4. **`repository/BookRepository.java`** and **`repository/MemberRepository.java`** — these show how data is stored and queried in memory.
5. **`model/Book.java`**, **`model/Member.java`**, and **`model/Loan.java`** — these define the core entities and their state transitions.
6. **`util/InputUtils.java`** — read this last to understand the console input helpers used by the UI.

A practical first step would be to follow one complete user journey, such as adding a book, registering a member, borrowing that book, and then returning it. That path should touch most of the important classes and make the overall design clear quickly.

### Key entry points and references

- **Application entry point:** `Main.java:7`
- **Console UI:** `ui/ConsoleUI.java:11`
- **Library operations:** `service/LibraryService.java:10`
- **Loan operations:** `service/LoanService.java:13`
- **Book storage:** `repository/BookRepository.java:8`
- **Member storage:** `repository/MemberRepository.java:8`
- **Book model:** `model/Book.java:3`
- **Member model:** `model/Member.java:3`
- **Loan model:** `model/Loan.java:5`
- **Input utilities:** `util/InputUtils.java:5`

If you are extending the code, the safest place to start usually seems to be the service layer, because it already centralizes the behavior that the UI depends on.