Mike AbiEzzi
Ranked 42 in Phase 1 with 62 unique views, 18 counted upvotes and 11 counted downvotes

About the author

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, meet DDD

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:

  • How communication is key, and language should be ubiquitous and exact in both code and discussions
  • Aggregates wrap up a complex set of domain rules around a tight knit group of models
  • Value objects remove unnecessary coupling and complexities
  • Repositories consolidate and express how object retrieval is important to the domain
  • Services represent natural transactions of a domain
  • When and when not to use DDD, especially with Rails

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.

Previous Next


  • D87dddeb300217e6c6574f5ffae220be?d=retro Nikos Dimitrakopoulos suggested 8 months ago

    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" :)

  • Profile_image?user_id=215108925&size=bigger Zalewski Leszek suggested 8 months ago

    I would appreciate some sum-up in list what will be discussed in the talk ;)

    Best Leszek