Master Data — Architecture & data
Dependency flow
Master Data is widely read, but mutations still need the right owner. For example, account holder avatar updates modify Contact, not Account.
Boundary rules
| Rule | Meaning |
|---|---|
| BU is a security/config boundary | Token/payment/customer/account queries must apply BU scope where required. |
| Account Holder is Contact | Account holder avatar is Contact.ProfileImage, not Account.ProfileImage. |
| Program setup differs from booking runtime | Editing TPS/TermProduct does not automatically rewrite confirmed bookings. |
| Image crop policy depends on field type | Avatar is 1:1; wide course/activity images are 16:9; generic uploads are exempt. |
| Site/program links affect availability | Booking/payment/subscription read these configs but do not own them. |
Main data
| Group | Data |
|---|---|
| Organization | Enterprise, BusinessUnit, Org, site relationship, custom URL. |
| Customer | Account, BusinessUnitAccount, Contact, account holder relationship. |
| Attendee | Attendee, measurements, profile/system image, product config. |
| Program | Term, ProgramCategory, Program, TermProgramSet, TermProduct. |
| Links/settings | Site-program category link, booking rule options, category payment option. |
Event side effects
Many master data changes can publish EntityEvents for history, notifications, or projections. Events do not move ownership away from the source aggregate.