As a consultant working with a new client every 3-6 months, I've had my fair share of working on complex domains, and it can be ugly. I've been actively practicing domain driven design to take the ugly out of what should be a beautiful expression of a domain. With past trials, failures, and successes, I hope to share the lessons I've learned with one of the best open source communities that I enjoy so much, ruby and rails.
Aside from enjoying the art of expressing a domain in code, I mainly enjoy helping startups make those tough, strategic decisions on how and when to use technology to build their business, with the challenge of maintaining speed of delivery and quality.
Outside the context of staring at a computer screen, I retreat to nature, trail running, skiing, mountain biking, and pretty much anything else not computers.
Rails applications are great for simple domains, but what if your domain is complex?
Modeling complex domains "the Rails way" without the right foresight in architecture can bring you a world of hurt. Going down the road of creating insufficient decoupling and organization of models and responsibilities can quickly create incomprehensible webs of domain logic, halting sane, sustainable growth, and ultimately bringing you to your knees.
At want point is "the Rails way" not enough? And what is this DDD?
We'll explore exactly what Domain Driven Design is and how a set of techniques can guide the architecture of your domain.
I'll talk about:
No matter how complex your domain becomes, it will stay easy to grok by a fresh pair of eyes, flexible enough to continuously change and grow, and ultimately make sure you continue to be that happy developer that Rails and ruby wants you to be.
Can't disagree with Leszek, I would also like a little more break down of "how a set of techniques can guide the architecture of your domain" :)
I would appreciate some sum-up in list what will be discussed in the talk ;)