Why User and Person Are Different Concepts
When I started redesigning my Identity Service, one of the first decisions was separating User Accounts from Persons.
At first it seemed unnecessary. Most applications have a users table and store everything there. For many systems, that works.
But the deeper I explored real-world scenarios, the clearer it became: User and Person are related — and not the same.
The common approach
A typical application starts like this:
User
├── first_name
├── last_name
├── email
├── phone
└── ...
Simple. Easy to ship. The pain appears when the business grows.
Side by side
| User Account | Person | |
|---|---|---|
| Exists because… | The software needs authz / sessions | A human exists outside the app |
| Lifecycle | Created, suspended, deleted by the system | Continues even if accounts vanish |
| Multiplicity | One person → many accounts | One identity across contexts |
| Owns | Credentials, permissions, sessions | Legal identity, orgs, citizenship |
User belongs to the system
A User Account is a technical concept. It exists because the software needs:
- Authentication
- Authorization
- Session management
- Access control
Without the system, the User Account does not exist. The software creates it and manages it.
Person belongs to the real world
A Person exists independently of any application. The software only represents that person.
Subtle on paper. Decisive in the schema.
Real-world pressure tests
A person can have multiple accounts
- Personal account
- Organization account
- Partner account
Same human. Different access surfaces.
A user account can disappear
Deleted, suspended, archived — the person still exists. Collapsing both into one entity makes recovery and audit messy.
A person can belong to multiple organizations
Employee, contractor, customer, shareholder — cleaner when Person is independent.
My model
Instead of making User the center of everything, Person became the hub:
Person
│
├── User Account #1
├── User Account #2
└── Organization Employee
- Person → real-world identity
- User Account → access to a specific system
- Each has its own responsibilities and lifecycle
Benefits
| Benefit | What you gain |
|---|---|
| Cleaner domain | Schema mirrors reality |
| Flexibility | New account types without rewriting “the human” |
| Reduced coupling | Auth changes don’t thrash person data |
| Org modeling | Roles without stuffing everything into users |
A lesson about architecture
Many architectural problems start when we combine concepts that look similar but represent different things.
User and Person are one of those cases. Related. Not the same. Recognizing that early prevents a lot of later complexity.
Takeaway
Authentication is usually the easy part. Modeling reality is the hard part — and it often starts by splitting User from Person.
Continue with Contact Information as an Aggregate.
Canonical version. Also on Medium.