I have read through a number of posts on Software Engineering but am unable to find a suitable solution for the problem my team and I are trying to solve.
We are building a system where we have multiple Actors / Personas, for example: an application user, patient, staff member, practitioner etc.
As you can imagine each of these entities share common attributes and also have their own unique attributes.
When a user signs up to our system we create their account on an IAM server we are using, in this case Auth0. The above Actors are also Roles that are assigned to each account in Auth0.
The way the system was built initially is that if you are a Practitioner and now also want to be a Patient, then two records exist in the system, which seems inefficient.
We are looking to rework the User design in the system and want to know what the best approach would be for this.
We can have a single User Service, this would be responsible for creating and managing the Users in the IAM application, setting the required roles and updating the metadata that is required for AuthN and AuthZ, this would also store all the common attributes for each User Type.
We could then create an entity in the other services that link back to the User with a User ID. Any changes, for example to Patient information, that would need to be added to Auth0 could be sent to the User service via an Event.
The main issue we have is when it comes to searching, as the data that could be searched over can exist in two separate applications. If the above design seems appropriate, would the best option be to then add an aggregation service that handles just search? This too would end up duplicating data, this store or search engine would then also need to be kept up-to-date.
Is there perhaps another approach to this that has been implemented? This seems to be a common problem when it comes to Users in particular.
Thank you in advance for any advice.
UPDATE - 24/06/22 Hi @BerinLoritsch
Thank you for you answer, I believe I haven't described my problem correctly.
We have 3 microservices, each governing separate, rather complex domains.
- Patients and all Medical Data
- Practitioners and Staff Members
- Mobile Application Users (the mobile app has a subscription component that allows anyone not just Patients, to get useful medical information), I apologise if this seems vague, as I am under NDA.
There are 4 "DB" entities, an
Across the 3 Microservices we are storing a large amount of duplicate information for example:
- First Name
- Last Name
- Email Address
- Telephone Numbers
But each model also has a large amount of unique attributes assigned to one another.
With the above in mind, let me explain what I consider our "Worst Case Scenario"
Given the way the API is currently designed. If a Practitioner would like to see another GP, they would create a Patient entity (this role would also be assigned to their IAM profile), and if they wanted to use the Mobile Application, then another entity would be created (role also assigned in Auth0).
So if they update their information in one place we need to update it in 3 other locations. The data models also don't know about one another.
So the design I proposed consolidates all the Common Information as well as API interaction with Auth0 into a single application, while storing all the unique domain specific information in each of the relevant Microservices with a
userId key that links back to the
User model (new model that would be added).
But if the information is segmented like this, then we fetching or searching the data needs to be "joined" across microservice boundaries, so we could create a new application that deals with this in isolation.
Please let me know if I am still not clear.
@BenCottrell thank you for your response, I shall do some research on data governance.