You can create a model that does not extend from ActiveRecord and this model class could possibly manage other ActiveRecord model classes. This Super Model class can have all the business logic related to that concept. So you can have model classes that represent the domain model which is not concerned with any persistence. You can also create your own DSL that will encapsulate your domain logic and use it in the non-persistent model classes.

I think that using pure Ruby is a valid approach for domain driven design. I hope to have a more informed opinion soon

The start point of rails is a database schema. In some ways you could argue that this means that rails is data driven. A model and an interface are derived from the schema. The model however can be a real domain model and most implementations use it as such. The database starting point is simply the means the domain sketches must be translated to the database before domain code is generated. Not quite the ideal way for ddd, but workable and better than most.

From an OO perspective the real issue is the way active record integrates with the domain model. Because the object derive from active record there is a tight coupling between the domain model and the persistence library. It is however a compromise that is often made, in Java as well. Most of my domain models derive from observable creating a similar coupling. I really want a framework that generates persistence and presentation based on a domain model, but with the current frameworks there is always a compromise. for some this is annotations, other require xml or some other descriptors and some require a database schema…

On Ruby for your enterprise domain model I don’t really see a problem. Sure, the Java compile could catch some things, but mostly syntactic error not the functional ones. Unit test should be written either way and will catch most syntactic errors as well. The real reason I like Ruby for domain models is the interactive mode. While i’m developing a domain model i can load the objects in irb and test them on the fly. If the model is complete i should be able to play the usecases from the prompt just by creating domain object and calling business methods. If find this the best way to test if my domain model really supports the usecases. the closest thing in Java are unittests (which don’t really count as i have these in Ruby as well) and the scrap pages from eclipse neither of which come close to the interactive and direct feedback of irb.

In my view of ddd, there’s really only on possible type of entrance point into the domain classes, and that is business methods, based only on usecases. Business methods usually do not equal crud functions; they are task-oriented, where crud methods are data-oriented. Furthermore, the domain classes contain only those methods needed to perform the business methods, and the database model in its turn only serves to persist domain classes (without the domain knowing).

By the way, I haven’t been using anything BEA for a long time now; it’s just me and my Eclipse. Maybe I’ve become too dependant on it, so much so that I can’t imagine domain coding without it. There’s something else though. The reason why I see Rails at the frontend side of an enterprise environment is because that’s where Java really sucks (if you dislike BEA Portal, try using bare Struts). And that’s where Rails could shine and win people over. Domain classes and business logic don’t need rapid development. But that webshop needs to be online yesterday!

(Oh, and isn’t cleaning up the controller and moving code to the model just a matter of proper object oriented design?)

I must admit I am running through greenfields throwing Ruby on everything that moves, small scale if you will. But scale is irrelevant and you should realize you’re wandering BEA city still drunk on it’s code generating tools. But Ruby will seep into the cogs of the enterprice; glueing incompatible worlds together, replacing business rules with a pretty DSL, and you will even find domain models being served by packs of rails mongrels. Charles and Thomas already pickaxed their way into Sun to bring us the tools. It is time to educate the programmer next to you and show them, don’t tell them but really show them, it’s cool stuff.

And oh, I don’t want to alarm you but the Java compiler doesn’t check your back it just tells you the code will run without knowing if it will run in the right direction. If you want to rely on tools the check your writing why stop at the compiler, why not use PMD, Bugfinder and all those other tools. To me this seems like the false sense of security the war on terror is bringing. The best cover is writing tests, test ensure your code is running in the right direction and still does after (manual) refactoring, basta!