Use a repository to encapsulate the logic for retrieving and persisting domain information. Keep that responsibility behind a domain-facing interface so database and library details stay in infrastructure rather than spreading through the system. section 1.4 section 6.1.4
This separation controls complexity over time: callers depend on behaviors such as finding and saving employees, while one implementation handles the persistence technology. Changing database access or adding caching can then remain localized. section 6.1.4
Employee persistence with a replaceable implementation
Define the required behavior without exposing its storage mechanism: interface EmployeeRepository { Employee findById(int id); Set<Employee> findByLastName(String lastName); void save(Employee employee); } Implement it in infrastructure, where Hibernate, Postgres, and caching can be handled. A HibernateEmployeeRepository can check a cache before querying the database, without changing the rest of the system. section 6.1.4
Treat the repository as a practical boundary, not an excuse for unnecessary elegance. Its value is clearest when infrastructure changes independently; interface design still requires care, and caching can introduce complications beyond this small example. section 6.1.4
