I’m developing a monolithic application in which 3 types of accounts can live : Admin, Teacher and Student.

They all need an authentication mechanism but expand to support various types of operations (some operations are reserved to teachers, other to students).

My concerns is about creating a new account. I’ve devised two potential solutions so far.

• Using Two Aggregates (Account for the auth mechanism, and either Student, Teacher or Admin for the account type and associated actions) but that would imply creating two aggregates in a single transaction. It’s common wisdom to avoid updating two aggregates in a single transaction, but there’s nothing said about creation.

• Nesting Entities into the Account object, one per type of account. Hence, the Account aggregate would have an entity Student, Teacher and Admin, 2 of which would be set to null and only one bound to an existing entry. It would act as some form of discriminated union and would prevent me from creating multiple aggregates at once, but it feels kind of weird to deal with this kind of AR.