[LRUG] Domain-driven design talk

[Matthew Willson]

Alex,

> I *also* think that of the major Ruby ORM libraries, only Sequel is really aligned with DDD in the first place, so if you're using anything else you've already compromised the model (although again, possibly that's a discussion for another time).

I just came across your December LRUG talk on this, and have a few more questions for you if you don't mind...

Essentially I'm wondering if you've come across any good libraries or techniques for implementing the Repository/data access layer of a DDD setup in ruby, in particular any approaches to data mapping (in the proper sense of the term).

We're already using Sequel, but I'm keen to move from Sequel::Model to more of a "pure data objects" model, and a repository-style approach for persisting them. I guess my main concern is the boilerplate required to duplicate all the association helpers and CRUD functionality which Sequel::Model (and similar activerecord-style ORMs) offer, when implementing a hand-rolled repository. Also wondering if there's any consensus on what a repository interface should look like in ruby, and if there are any generic ruby tools that can work with them?

This stuff is of course a lot more standardised in the Java world, but I see no reason why ruby can't be a good fit for it too, if not better in some ways. Just might require a little bit more in the way of library support to make the experience a smooth one.

As background in case anyone's interested: our domain model is music metadata; when starting out I think it's safe to say that the more ActiveRecord-style ORM approach was more convenient for agile development purposes, but since we've started getting serious about scaling the thing, more and more different persistence and transport mechanisms come into play (so not just a canonical mysql db, but a JSON cache, search index, message bus, separate data warehouse for reporting, some user-specific repositories etc). Running this all off Sequel::Model classes and associated hooks can get a bit messy, with model classes feeling quite over-burdened and overly coupled to infrastructure logic.

-Matt