Appearance
Member module overview
A Member is the main type of user on our platform.
During registration (after successful payment), the application creates a new Member and a Membership.
A Member and a Membership always come in a pair, it’s not possible to create a Member without Membership. The reason we distinct Member and Membership is that a Member may have a history of Memberships: for different purposes, the application needs to stack all changes in the Membership history for every Member. So, it’s correct to say that a Member has many Memberships, but only one (the latest) Membership is active at a time. You can read more about Memberships in the Membership module docs.
When a Membership is expired, the app cancels both the Member and the Membership.
There is one more type of User on our platform: Mentor (who are not Members, that means they have their own profiles, logic, even login page is different).
Other special types of users are implemented as Members:
- Admins
- Educational Partners
Almost Member
There is one more special type "user": AlmostMember (a user who started registration). AlmostMembers can’t log in, it’s just Lead / a record in a database. Technically, they are guests, but the app knows a bit more about them (email and name).
Technical Challenges
The main challenge is to keep the Member class small (avoid a God Object issue). It’s not so easy because a Member may have relationships with every module on our platform:
- local groups (can join multiple groups)
- courses (can be enrolled into multiple courses)
- discussions (can create discussion messages and topics/threads)
- etc.
To solve this problem, we usually create interfaces and traits to help keep the Member model small.