When should you use GORM Data Services instead of dynamic finders?

Dynamic finders are still perfectly reasonable for quick, one-off lookups scattered through application code, but GORM Data Services are the better choice once a query needs to be reliable, reused across the codebase, or verified before the application ever runs.

Reach for a Data Service when: the query logic is complex enough that a typo would be genuinely costly to discover only at runtime; the same data access operation is called from multiple places and deserves a single, well-defined interface rather than several scattered dynamic finder calls; the project needs multi-tenancy support, which Data Services handle cleanly through @CurrentTenant; or the team simply wants persistence logic that's easy to unit test by mocking an interface, rather than exercising real dynamic method dispatch in tests.

For a genuinely trivial, single-use lookup buried in a controller or service method, a dynamic finder's brevity is often still the more pragmatic choice — the two approaches coexist in the same GORM-based application rather than being mutually exclusive, and picking between them is a judgment call about how much that particular query deserves a formal, compile-checked home.