Let's talk about 'Members'

[karimmtarek]

I'm working on this #148 and according to the Domain-Model each member has_many talks, I still can't figure out:

• What's a member?
• Why is it different than a user?
• Do we really need it? or adding a enum field to the user model with different types [:member, :admin, :guest, :whatever] can do the trick?

[benichu]

I'll give you my point of view later today, if that's Ok :)
But anyone is free to chime in anytime...

[karimmtarek]

@benichu sure :) I'm looking forward to it.

[cawel]

Here are a few hints, from what I understood:

• The purpose of a User is to be able to log in.
• A Member cannot log in (if it is not associated with a User, i.e. member.user_id = nil).
• A Member refers to a person in reality, e.g. the talk "What's new in Rails 5" could be given by "Donald Henry Howard" (aka DHH ;) ), and that person would be represented as a Member entity in db. "Donald Henry Howard" comes from Australia and is only staying in Montreal for 2 days and will never have to log in. Still, his picture, twitter/github handles and email would still be persisted in db as a Member.
• If at a later point in time "Donald Henry Howard" needs to log in because he wants to be more involved with the Montreal.rb community, then we'll create a User for him. And his already existing Member model will then have the user_id of that new User model we've just created for him.
• I hear you saying "why not use the User model for both of these scenarios?". Sure, that could have been possible. But I think @nicholasjhenry was attempting to better reflect reality by distinguishing between those 2 entities in the architecture. And we'll probably observe in the long run that we'll have a ton of Member's, but only a few User's. Plus, from a security point of view: less users (people who can log in) mean less weak passwords to worry about :)

[benichu]

I agree 100% with @cawel

I would just add:

• Member is a facet of real people interacting with our website's business domain, we could, later on, decide to implement other facets...
• User seems to implicitly refer to people, but because the responsibility of that class is to deal with authentication and authorization, it could also be referring to non-human users (like an external API client...). Maybe the proper name for that class should be Account which does not presume a human-only bias... If that makes any sense at all 😄

If you have a chance I recommend watching this ruby tapas episode (#346)

[karimmtarek]

@cawel @benichu Thanks for taking the time to explain this 👍 I really appreciate it.

[cawel]

@karimmtarek Since you're the one who opened this issue in the first place, feel free to close it if you feel satisfied :)

[karimmtarek]

I feel satisfied 👍