If you already have a web service that handles your domain and business rules, you can turn off db support.
If you do that, your grails app is effectively a thin web layer on top of another service. In this case, if you are going to enforce business rules, you could still do it in service/domain layers. However, I would not do this, and certainly not any complex validation, because the service should be your single source of truth for the app, and you don't want to duplicate business rules in 2 apps.
I would still use controllers for handling web requests, and services for interacting with the other service. I would also have some sort of simple domain layer for passing data thru the sections of the web layer (i.e. services return anemic domain objects, controllers serialize them to the client however makes sense). The majority of the work would be in the service layer, which would serialize and deserialize the communication with the other service.
Based on your comment, Grails is a fine technology for building your server layer. Why would you think it isn't? Grails bills itself as a rapid development environment; it provides everything you need for all layers of a standard web-app. You don't lose anything; quite the contrary, you gain quite a bit, such a integration with persistence, spring, a robust testing framework, etc.