A question regarding Domain-Driven Design (DDD) and architectural design that I suspect is likely common to many, if not most microservice apps. So, I'm wondering how people might approach this as a common design pattern. The idea is, that as a user of the system, a person is a different type of entity in different sub-domains:
• In Cognito, a person is a "User" who signs up, logs in, forgets and resets passwords, etc. Authentication and authorization-related stuff.
• In a banking app, a person is a "Customer". They check account balances, transfer money between accounts, etc. In my karaoke backend app, a person is a "Singer". They manage favorite song lists, request to join a queue to get a chance to sing, view their performance history, etc. In other words, a person is a different kind of entity with different properties in different sub-domains.
• What are some common approaches to link the "User" in Cognito with their "Entity" in the rest of the app, so that auth concerns are orthoganal/cross-cutting to their business-related activites in the app?
• Specific to AWS serverless/sst, my thoughts on a good design pattern is to use triggers, such as Pre-Signup or Post-Confirmation to create a banking "Customer" or "Singer" or what-have-you entity in DynamoDB that uses their unique identifier in Cognito as their partition key in the singers or customers DynamoDB table.
How have other sst, or serverless in general, developers been approaching this problem?