Traditionally, we have named the entity that represents an individual using the software as a User.
(In past implementations, we have used UserAccount).
In this implementation, we have the chance to diverge from that thinking.
The word Account could also represent the billing or buyer use cases.
The end-user is really the user of the software.
In B2C they are also the account holder or buyer. In B2B they are often not both the end-user and the buyer - but sometimes can be.
Since we are trying to define a model to include both B2C and B2B, perhaps we are better off making this distinction early on.
I want to propose the entity for an end-user to be called EndUser which represent their identity (ID) and associated use cases. This entity is referenced by other subdomains of course.
We still use Organization to represent the grouping entity (i.e. company in B2B, or team/project/workspace etc in B2C), but then this frees us to use the Account entity for the buyer use cases, their billing, subscription etc.
Traditionally, we have named the entity that represents an individual using the software as a
User. (In past implementations, we have usedUserAccount).In this implementation, we have the chance to diverge from that thinking. The word
Accountcould also represent the billing or buyer use cases.The end-user is really the user of the software. In B2C they are also the account holder or buyer. In B2B they are often not both the end-user and the buyer - but sometimes can be.
Since we are trying to define a model to include both B2C and B2B, perhaps we are better off making this distinction early on.
I want to propose the entity for an end-user to be called
EndUserwhich represent their identity (ID) and associated use cases. This entity is referenced by other subdomains of course.We still use
Organizationto represent the grouping entity (i.e. company in B2B, or team/project/workspace etc in B2C), but then this frees us to use theAccountentity for the buyer use cases, their billing, subscription etc.