Membership

What It Models

The membership record gives a person or organization one enduring holding in a program. Renewals add periods to that record, preserving the membership number and join history. The record combines lasting identity, member preferences and operational caches.

Identity and Attributes

The program determines whether identity includes a chapter or another unit and which source assigns the membership number. Flow-down and assigned holdings also identify an organizational parent. A first purchase can create an unnumbered record while payment is pending. Suspension withholds rights independently of dates; a Commerce fence prevents competing purchase work without itself changing dated standing.

Relationships

Terms describe the holding’s coverage. Affiliations attach units to those terms, while applications and history reference the holding for their own work. People, organizations, programs and units remain records owned by neighbouring modules.

Invariants

Database constraints protect principal and derived identities and the consistency of owner and hold fields. Service checks validate identity binding and restrict direct staff work to principal holdings. Commit-time history validates attribution before the change becomes durable.

How It Is Stored and Shared

The memberships service owns the holding, its versions, lifecycle entries and custom values. Other service modules in the same macroservice read those records for checkout, decisions, billing and reporting. Metadata enables the shared custom-field capability, although the available write operations do not accept custom values.

Open Design Questions

Product still needs an owner-transfer and CRM-merge policy and usable write paths for member preferences, join-date changes and custom values. Existing storage does not establish those user operations.