Complete Application

Knowing how to write a controller, a repository, a form, and a security rule isn't enough to know how to write an application. The individual building blocks are simple; it's their assembly that creates difficulties, because it raises questions that no isolated lesson poses.

Where should the rule "you can't borrow a book if all its copies are checked out" go? In the entity, which knows its copies but not the other users' current loans? In the service, which sees everything but then mixes two concerns? In the controller, which has no business handling it? The choice has lasting consequences: if the rule is misplaced, it will be bypassed the day the API performs the same operation without going through the same path.

Another question that only appears at assembly time: an operation that touches two entities — decrementing availability and creating the loan — must succeed or fail as a whole. If the transaction boundary is in the wrong place, the application will occasionally produce inconsistent states that no one will be able to reproduce.

This final lesson therefore builds a complete feature — borrowing a book — by traversing all the layers and justifying each placement. It then adds error handling on the page side, message internationalization, and integration tests that verify the whole rather than the pieces.