Domain-driven Ruby on Rails??
Yesterday evening I attended a session on domain-driven design (ddd) at Sogyo‘s offices, a nicely converted farmhouse located somewhere in the center of Holland. I was amazed to hear Ruby and Rails being used as an example of domain-driven development. One of the presenters even claimed that Dutch Rubyists Remco and Michiel (who reached 2nd place at this year’s RAD Race, a programming contest) had done so well because they were able to work domain-driven, thanks to Rails.
Surely he was joking. If there is one data-centric framework out there at the moment, it has to be (my beloved) Ruby on Rails. Let’s see…
- Rails’ “domain” classes (the model) are literally an implementation of the Active Record pattern, which has a direct coupling to corresponding database tables.
- As a result, Rails’ model classes correspond directly to database tables; a change in your table (e.g. an extra field) is automatically a change in your model class.
- Worst of all, DHH is actually on a mission to model the whole world under the constraints of CRUD.
I really don’t see how you can call this domain-driven. This is not to say that you couldn’t implement a domain model (as in ddd) in Ruby. But in my opinion, that is not what Rails is about. Rails is limited to the presentation layer, so its model is nothing more than a view model. For small scale applications that’s good enough. But if you need your business logic to be available independantly, to be accessible from multiple views (presentation layer applications), you’ll want to put that business logic in a separate layer, not in the model of one of those views. That is how I see “enterprise Rails”: as a tool to rapidly develop presentation side applications that use and combine existing business services (WS, EJB) (using JRuby on a Java application server).
The question remains if a domain model could be implemented in Ruby (not Rails). Technically, you could, of course. But would I want to? I’m not sure. It’s very reassuring to have the Java compiler checking your back and Eclipse’s refactoring tools at your disposal. You’d have to have some very tight unit testing to replace those and still feel safe about any changes you make. I mean, we’re potentially talking about a large company’s vital business rules here. Would I feel comfortable duck-typing those? On the other hand, there’s Ruby’s excellent DSL capabilities that would come in very handy for specifying exactly those business rules. What do you think?
2006-11-30. 9 responses.
I don’t understand your reasoning, maybe because I don’t understand the domain-driven philosophy. But as I understand it, it’s about putting back model logic where it belongs, in (or close to?) the object model. This is exactly what DHH’s CRUD mission is about, cleanup the controller and move logic to the model layer. And this is perfectly in sync with Skinning Controller Fat Model Jamis Buck wrote about. These two movements make Rails a interesting contender to implement a domain model and webservices to make them available.
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!
Remco, you’re in luck. At this year’s JavaPolis, the domain-driven guru Eric Evans will do a session on domain-driven design.
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?)
The way i see it, domain driven design is a way of working. It’s about creating a coherent domain model and placing this at the center of your application. All other aspects are secondary. From that perspective any framework that takes those aspects out of the development supports ddd.
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.
[…] Danny’s Blog Pondering Programming and Poetry « Domain-driven Ruby on Rails?? […]
I’d say Rails is far from anything related do DDD. It is to closely linked with persistency issues to qualify as such (but hey, it’s opiniated!). As per usual, maybe we should look at Smalltalk once again. It has a lovely persistency framework called Glorp. Check it out
I think that Danny’s observations are spot-on. Rails really isn’t friendly to DDDesign as described by Eric Evans. I have spent the last few days slogging through Evan’s book whilst working on a new Rails project. It’s not an easy fit.
I think that using pure Ruby is a valid approach for domain driven design. I hope to have a more informed opinion soon 😉
Domain Driven Design has nothing to do with the language or framework that you use to implement a solution. Ruby is a object oriented language. Rails is built on top of Ruby. There is nothing that holds the developer back from using Ruby to implement a solution that is the result of DDD.
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 agree with Danny and Peter … there is difference between what the domain driven model is about and rather then just focusing on the data centric aspect of components and objects in an application as implemented by Rails.
I prefer grails for this reason … and I work in both environments.
[…] Domain-driven Ruby on Rails?? […]