Like many other new web application frameworks (e.g Rails, Spring Roo) Grails with its GORM has taken the approach that separate DAO or Repository layer is removed. Is this a bad thing or is it just a change in implementation that doesn't affect conceptual design?
In Grails persistence query functionality is added to domain entities by injecting set of static finder methods (e.g Customer.findByFirstname, Customer.executeQuery). I find that there are two main issues with this approach.
At implementation level everything is fine - every class still contains code for implementing single responsibility - business rules in case of domain entities and database access in case of finder/plugin. Unfortunately we still mix these roles at conceptual (API) level. For example Order will now not just have methods like submit or reject but also findAllByCustomer and createCriteria etc.
I don't want to go into detail whether static methods in general are good or bad but many drawbacks of static methods do not apply to Groovy. Unfortunately one drawback still remains - ease of creating dependencies. We can easily use these query methods from any other place in the system without even noticing what kind of design tangle we are creating. Of course this simplicity can be also very useful since it saves us from unnecessary plumbing when given dependency is in accordance with general design.
In summary I think the approach taken by GORM is not inherently bad. It doesn't really violate the principles of DDD since it still does a good job at allowing us to concentrate more on the domain model. However I don't think that we have really got rid of the DAOs or Repositories we have just changed the way they are implemented.