All Hail the Command Object

This is a follow on to Simplicity in Web Architecture – Beware the Stateless Service

In that article, I gave my opinion on the Stateless Service programming model, and why I think it has been overused and touched on some of the issues it has caused.

It developed out of my unhappiness with the way I see code layed out in many Spring and Grails applications. The Service layer becomes stuffed with all the important logic, kept away from the domain and without much in the way of support to be had from the excellent Object Oriented language that Groovy is.

Peter Ledbrook recently wrote a blog post about the future of Grails, which sparked some deep thoughts about where Grails is heading as a platform.

As a long-term Grails user with interests in programming in the large, functional languages, DDD, CQRS, and high-volume HTTP, I’ve been contemplating what the future holds for this framework.

The Changing Landscape

The industry has changed significantly since Grails was born. Grails emerged from the Spring/MVC consensus - essentially designed to be “Java/Spring web development done right.” It was, and continues to be, a better Spring MVC paired with a better Java (Groovy). This approach has been beneficial to the industry.