La Librería

The case study

Problem

Managing books, members and loans with rules that always hold —stock, per-member-type limits, no duplicate loans— without ever leaving state in an impossible value.

Solution

Layered architecture with inward-pointing dependencies and a generic Repository<T> interface; a rich domain where entities protect their invariants and loan rules live in a per-member-type enum.

Outcome

61 JUnit 5 tests, an executable fat jar via Maven and documentation of architecture, domain and design decisions. MIT licensed.

Process

Development process

The reasoning behind the technical decisions: why each technology was chosen, what challenges came up and how they were solved.

1. 01

   Layers and a generic Repository<T>

   The architecture points its dependencies inward and uses a generic Repository<T> interface that abstracts storage. Because of that, today it persists to JSON but could switch to a database by changing a single implementation, without the domain ever noticing.

2. 02

   A domain that protects its rules

   Instead of scattering validations, the entities protect their own invariants: a loan cannot exist without available copies, and per-member-type rules (quotas, limits) live in an enum. State never lands in an impossible value, because the object refuses to be built wrong.

3. 03

   Confidence through tests

   I wrote 61 JUnit 5 tests over the business rules, which are the critical part of the system. That safety net let me refactor fearlessly and document the design decisions. The project ships as an executable fat jar via Maven.

Repositories

Commits

1. 
   Cambios varios

   0cd85bc·Eduardo·3 weeks ago

2. 
   Initial commit

   7435d4c·Eduardo·3 weeks ago