Domain Orientation and Rails

Over the last two years I've switched my development target to web apps. Though it started earlier than this, while I was still building TekCAD I was purposefully writing Java and Swing to earn my rent. The transition to full-time J2EE work that I made was good, but when I started doing Ruby and Rails my application-building days got much better.

Ruby and Rails are just vehicles, however. While they make it easy to put together new web apps, the opinionated style of Rails does not always jibe with what I've learned through experience about what end users expect. Users are domain experts. Given their expertise, They certainly don't look at problems the same way as application developers do. They want their complex understanding of a domain distilled into clever interfaces that save them as much effort as possible while still maintaining enough safety to keep them from making horrific mistakes. It's often quite tricky to develop these sorts of domain-expert applications, but that's what these users want. The raw-Rails philosophy enforces a certain perspective, focussing on exposing objects and enforcing rules and validation - however without considerable domain-bias worked into the application, the result can feel relatively flat.

This should be expected. Rails is about building applications, not understanding domains. The two problems are orthogonal. Web applications that are domain-oriented can be realized in any web framework. Rails just makes building them easier for developers.

As I've worked forward through these last two years, learning Rails with an emphasis on developing good domain-oriented applications, I find myself writing smarter and smarter controllers and depending more heavily on state stored in the session. This is somewhat contrary to the stateless mode preferred on the web, but I find it is typical for domain sensitivity. And surprisingly, I'm discovering some good new stuff.

What's good is this: the switch to Rails has given me the opportunity to re-examine domain orientation. In the past I've had to work so hard just to get everything finished for everyone - what with slashed budgets, creeping features and accelerated schedules - that my consideration of domains as a thing unto itself has been myopic at best. It's hard to be philosophic when you don't have enough time for it. Only rarely have I had the chance to step back and look at the meta-level of domains with respect to application development. But Rails has given me more time. Now I am refactoring my thinking as I refactor my code. I'm beginning to see shapes coming into focus: fundamental principles are being revealed about what it means to build software enriched with domain specificity.

Geekhood showing, I am salivating at the thought of capturing this knowledge. More is certainly to come...