Design the object model and public APIs for the software that runs a single branch of a community lending library. Staff catalog titles and their physical copies; members search the catalog, borrow and return copies, and place holds on titles whose copies are all out. This is the in-process domain core a desk terminal or a REST layer would drive, not the UI or the database.

Operating context. One branch, tens of thousands of catalog titles, each with one or more physical copies (barcoded items). A member may hold a bounded number of loans at once; each loan has a due date derived from a lending policy and the borrow instant. When every copy of a title is on loan, a member may reserve the title and join a FIFO waitlist; the next returned copy is assigned to the head of that queue for a limited pickup window. Overdue returns accrue a fine whose formula the branch tunes over time (per-day rate, caps, grace period, waivers for certain member classes). A single desk process serves requests, but multiple staff terminals may act on the same catalog concurrently.

Out of scope. The persistence layer (assume an in-memory repository seam for v1), authentication and staff permissions, the REST/HTTP surface, payment collection for fines (model the fine amount, not the transaction), and inter-branch transfers or a union catalog across branches.

What to produce. The class hierarchy (Title, copy/item, Member, Loan, Reservation, and the catalog/lending/fine services), the public API each class exposes, and the state transitions for a copy and for a reservation. Be explicit about: how a title's availability is tracked as copies come and go, how the fine policy is pluggable so a new formula does not touch the return path, how due dates are computed from an injected clock so the logic is testable, and how the borrow/return/reserve operations stay correct when two terminals touch the same title at once.