Domain-Driven Rails - Aloha on Rails 2009

As Rails continues to gain popularity, and the community behind it matures, Rails is thrust into domains of increasing complexity. As anyone who’s been developing in Rails for a while knows, Ruby and Rails are particularly good tools for modeling this complexity. However, very little emphasis has been placed on how to *manage* this complexity. “Domain-Driven Design” is a set of principles, patterns, and practices (detailed in a book of the same name) that help developers manage the complexity that comes along with working on large projects in interesting domains. The two ideas that I will focus on are Aggregates and Bounded Contexts. I will cover such topics as 1) your 1400 line user.rb - why it sucks and what to do about it, 2) management in the small: breaking up objects, designing aggregates, or, why not all entities are created equal, and 3) management in the large: identifying bounded contexts. This talk is intended for developers working on longer-term, larger applications that are running in production and providing value to the business. I think the ideas in it start to become useful when a Rails app hits the 10k line mark, and are crucial for managing complexity beyond the 30k line mark. It’s an advanced topic and is meant as high-level design and architecture (implemented in real code though!!)

"How do I become a better Ruby developer?"

Blogs, books, and bootcamps all promise to make you a better Ruby developer, but end up confusing you more.

What if you had step-by-step instructions on how to become a better Ruby developer?

Enter your name and email below and I’ll show you how to...

  • get better at Ruby in just five minutes each day
  • use testing, OOP, and refactoring to write professional-level Ruby
  • identify and learn new programming skills quickly