Relationships between entities in OO design

[Reed Law]

I asked Uncle Bob on Twitter, but I'll ask here again: how do you implement associations/relationships with Clean Architecture, or Entities-Boundaries-Interactors design? I'm trying to refactor a Rails app which just happens to be a payroll app, similar to what Uncle Bob uses in some examples. There are some complex relationships such as User -> has_many -> Shifts -> through -> AssignedShifts, and Schedule -> has_many -> Shifts -> through -> ScheduledShifts. Some of these can clearly be Inheritance, such as Shifts -> ScheduledShifts -> AssignedShifts. But how do I handle these relationships? Do I store them in the entities themselves in instance variables? Or do they go in Repository objects? It seems that a user having shifts is non-application specific domain logic. But I want to keep the entities ignorant of the database. Should I use relational algebra (with a gem like Axiom) to model relationships between entities? This seems a little like re-implementing the database at the model level. Am I not thinking in a properly object-oriented way here, or is this just the level of effort needed to separate business logic from persistence details?

[Mark Badolato]

On Fri, Oct 11, 2013 at 9:46 AM, Reed Law <ree...@gmail.com> wrote:

But how do I handle these relationships? Do I store them in the entities themselves in instance variables? Or do they go in Repository objects? It seems that a user having shifts is non-application specific domain logic. But I want to keep the entities ignorant of the database. 

I'm not 100% sure I understand quite what you're asking, but it sounds like you may possibly be confusing the EBI design and the separation between Rails' model classes.

You are correct in that the relationship should be defined in the Entity as properties (instance variables etc), and the database relationship (the persistence modeling) should not. The two should be separated. Have a look at the book Enterprise Rails. The full text is available at the author's site: http://enterpriserails.chak.org/full-text. While the book is now outdated in terms of Rails itself, the information and ideas presented are still applicable. 

The author does a good job of explaining how to separate out your model from your persistence. That sounds like what you need, again though, I may just be misinterpreting your question.

--mark

--

Mark Badolato 

Email:   mbad...@gmail.com

Web:     http://www.markbadolato.com

Twitter: @MarkBadolato

[Reed Law]

I am trying to use EBI with relationships between entities. Not ActiveRecord relationships but Plain Old Ruby Objects. For example, for a use case like EmployeePunchIn, the employee object needs to be able to find the current shift assigned to the user through an AssignedShift in order to tell if the employee is late or not. I may be over-dependant on ActiveRecord, but when it comes to implementing this the first thing I think of is ActiveRecord associations like has_many, through, etc. Am I just re-implementing these functions without reference to the database in my attempt to separate domain logic from persistence details?

[Uncle Bob]

About a year ago I worked with someone on a rails model that had lots of relationships.  We wound up creating a pure business model with a shadow hierarchy of ActiveRecord objects that included the pure model.  I don't remember the details at this point, but it wasn't too hard to work out the mechanism.  I _do_ remember that it kept the pure business model nicely decoupled from the Active Record model that backed it.

[Reed Law]

This is the approach we wound up taking. The business model hierarchy is actually a lot simpler than the ActiveRecord hierarchy because we can take advantage of OO techniques like inheritance. I plan to write up a blog post about the experience.

[Uncle Bob]

Please post a link to that blog when you've written it.  I'd love to read it.

[Reed Law]

Here is the promised blog post: http://www.smashingboxes.com/domain-logic-in-rails/

I welcome your comments and feedback.