Repository pattern for DB access (small, pragmatic)

Not every codebase needs full-blown DDD, but I still want a clean seam between business logic and SQL. A tiny repository module per aggregate gives me that seam, and it makes testing easier because I can stub repository methods rather than mocking the database at every call site. The trick is keeping repositories focused: expose intent-level methods like findByEmail or createOrder, not a generic query builder. When repositories go wrong, it’s because they grow into a second ORM. I keep the interface narrow and let the DB enforce constraints via indexes and foreign keys.