CESARDELATORRE
commented
6 years ago Thanks for the feedback! So, if using ASP.NET Core Identity you could extend it to support additional attributes for the customer. However, putting all the attributes of a User/Customer/Shopper ina single place is not usually the best domain model design in microservices and Domain-Droven Design. Best approach is to try to split the “fat entity” in multiple entities across multiple microservices or multiple domain models, even when they share the same IDENTITY.
For instance:
- User entity, just for logging and basic user info, not much more, in the Identity microservice like the one based on ASP.NET Identity.
- Customer/Buyer entity within the Ordering microservice (we have that one, in fact) with attributes you only need once a user has already bought.
- Additional entornes in additional microservices you may have like one for CRM might need additional attributes.
Think about Microservices as small autonomous apps, so each microservice should already have the data it needs, and have eventual consistency for the cases where you need some data redundancy between microservices’ entity models.
Async communication with eventual consistency should be ok if after login you don’t need additional info in the next 2 seconds or so.
Take a look to this section/chapter I wrote about this topic in Domain-Driven Design: https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/architect-microservice-container-applications/identify-microservice-domain-model-boundaries
Hope it helps. :)
ADringer
Hi,
Thanks for the excellent example of microservices. I understand that this isn't a production system so don't expect my question to be implemented, but want to understand how it could be.
In eShopOnContainers there is a separate service all to do with signing up and authentication (identity service) which makes sense, keep this separate.
However, it doesn't have an example of a domain model of 'customer'. In a real system I would expect an additional microservice around the customer which would handle things like customer's address, preferences etc.
If I was to add customer to the example I would have two options:
Add the customer model to the existing Identity service. This would work as when they register it will create the user within the same scope. However this feels like it's wrong as the Identity service should just be doing authentication.
Create a new Customer microservice to handle this bounded context. This feels like the correct approach as it's just dealing with the customer model, decoupled from identity. However I'm having trouble thinking of how this would be implemented in reality due to eventual consistency. When a user registers they would then be redirected to the site and would expect to be logged in. If the event hasn't been processed then the new customer wouldn't be found. Might have to do this synchronously?
Any thoughts around this? It seems a nicer approach to have the proper bounded contexts (customer, catalog etc) and then having identity sitting in front of that but completely separate, but doesn't seem as straight forward.
Thanks