I have been playing Spring Roo for a little while now, and when I'm not swearing at it because I can't remember the correct command (there appears to be some inconsistencies around the use of -class and -entity), I am pretty impressed.

Anyway, the only thing holding me back from recommending we trial it at my company at the moment is the focus on domain driven design. Now I have no desire to get in to a religious debate around the pros and cons of domain driven vs services orientated; I believe they are both valid architectures, and each has its own benefits and draw backs. However where I work we have chosen to use a services orientated architecture as we believe it best suits the projects we work on.

From a conversation I read on the Skyway blog between Ben and Jared, it sounds like Roo doesn't currently support a services orientated architecture. Now I know on one of your videos you showed using a services object within Spring Roo, however you had to write that object yourself.

The ideal situation would be for the DAO and business logic objects to be created automatically by Roo, similar to the domain objects. I know in your presentation you said you couldn't possibly know all of the methods we may want to use, and that is correct. However you could create the basic crud methods, as well as any finders we choose to add.

So to get to the real point of this post; If I wanted to create a Roo add-on that reused/extended the jpa add-on to create DAO and domain logic classes, where would I start? I would envision it as a choice when you installed JPA support (select either DDD or services), so you could use the same commands to create all of the fields for your entity.

Any advice would be much appreciated.

Thanks
Andrew