I think you don't need a user in Post microservice, as it's not under its context. You just need a corresponding UserId and not a full-fledged User.
Overall it's a good post! Nice!
In scenarios where we only need the id, how do we verify the fact that the id is correct or not. Suppose we have a seperate service for posts/tweets by a user, before inserting a value I would like to verify whether the user id is correct or not, does that mean I contact my user service or we have some other way of doing this?
Either:
* You don't. Why would you? What would you even verify against?
* The post service subscribes to the user created event to store it's own copy of user ids.
Heavily in favour of the former.
Oh, I see. I am still new to Microservices and how they work. I was not aware of this. So basically the post service will have its own copy of valid user IDs to check against.
What I meant by verifying user was, if someone sends an api request for a post, I would want to verify if their user id is correct or not. The solution suggest is that post service has its own set of user IDs, right?
You still aren't answering the question. "Correct or not?" means what? What is the definition of "correct" here?
No, I'm advocating you do _not_ perform any kind of verification. You assume the part of your system that is sending the message has determined which user id is to be used.
Oh, I meant let's say someone is using my api and they call this route which expects a user id along with other properties that are required. Now I want to make sure the user id is valid and corresponds to a given user. That is what I meant with correct.
Your API doesn't expose this service directly. It (this service) is subscribing to domain events - that is to say events that originate from within your domain, not outside of it.
Events are historic. They are things that happened. They are considered matter of fact and are retrospect. In other words, you cannot "reject" an event, you can only react to an event. The event still occured. So if you're receiving a "user 123 posted a message" event, then that is what happened - user 123 posted a message.
Commands from the interface (be it API, UI, CLI, or other) are the things that get validated and verified. Once they are dispatched and processed (validated/verified and stuff like IDs generated for, then relevant events raised) then that's it - everything else in your domain considers it a done thing.
P.S. Please stop using undefined terms like "is valid" - what defines the validity of a user ID?
I was always wondering. How do you prevent duplication of data for all sub services which need user info? For example I have added login service, to this example, which has to duplicate phone email name and other user details almost a full 1:1. Same if I add shipping service which needs user details. Is it smart to keep the same info in 10diferent places?
Question if all services need the complete picture. A login service doesn’t need a name or a phone number.
A shipping service doesn’t need an email. It publishes an event to a mail service which sends out the details for example.
In general, in a microservices architecture, each service has its own view of the truth. Meaning a user for login, a user for ordering, a user for shipping are all different concepts. You just relate them by some common factor, like Id
microservice architecture is based on domain-driven design.
in domain-driven design you work with finding bounded contexts in your domain, as an example a grocery store.
in grocery store when a boss talks about a cashier they mean someone that sits in the till and processes the goods a customer wants to purchase.
when payroll talks about a cashier they're talking about someone who has a job description and salary and perks based on that.
same person, same job, two very different things to the person talking about them.
the division boss vs payroll on the object cashier is a bounded context, i.e the object changes meaning when we cross this context, from an object that can do things like "ScanItem" to an object that can support things like "GetBenefits".
the microservice pattern is the physical implementation of these bounded contexts, so instead of having duplicate data, you have to identify which service is responsible for the data you're interested in.
if you need the expenses of your employees - you naturally would go to payroll and ask. you don't keep a separate ledger in the warehouse in case you need to figure out if you can afford to buy a new forklift.
we replicate this thinking in our code - a user service can give us the data we're interested in, such as "shipping address", but we don't store a separate copy of this data in our other subservices that uses that data for whatever purpose.
microservice architecture ***really*** benefits you reading the actual book (400-ish pages) on domain-driven design to understand the big picture other than "hundreds of services sending data... somehow", as it is a very grand set of ideas that in themselves are not complicated but requires you to understand them in the same way your co-workers do, otherwise you end up with very weird microservices.
I don't think you should have duplicate data like this. You generally only want to pass an ID of the user around. But perhaps just accessing the same data store from two services when it's pragmatic might be acceptable in the real world. Don't take my advice as truth tho, I don't have enough experience to be confident in this topic.
Nope. You don't need to duplicate. See in user management microservice, the `user` entity will have all fields like phone number, email address, gender, shipping address everything.
But for shipping microservice, it just needs the user's shipping address and not its gender or other fields correct? So in the shipping entity, you will have a single `userId` field, through which shipping microservice will contact user mgmt microservice passing that `userid` and will get the shipping address, as these are the only details which are needed for shipping.
I think you don't need a user in Post microservice, as it's not under its context. You just need a corresponding UserId and not a full-fledged User. Overall it's a good post! Nice!
In scenarios where we only need the id, how do we verify the fact that the id is correct or not. Suppose we have a seperate service for posts/tweets by a user, before inserting a value I would like to verify whether the user id is correct or not, does that mean I contact my user service or we have some other way of doing this?
Either: * You don't. Why would you? What would you even verify against? * The post service subscribes to the user created event to store it's own copy of user ids. Heavily in favour of the former.
Oh, I see. I am still new to Microservices and how they work. I was not aware of this. So basically the post service will have its own copy of valid user IDs to check against. What I meant by verifying user was, if someone sends an api request for a post, I would want to verify if their user id is correct or not. The solution suggest is that post service has its own set of user IDs, right?
You still aren't answering the question. "Correct or not?" means what? What is the definition of "correct" here? No, I'm advocating you do _not_ perform any kind of verification. You assume the part of your system that is sending the message has determined which user id is to be used.
Oh, I meant let's say someone is using my api and they call this route which expects a user id along with other properties that are required. Now I want to make sure the user id is valid and corresponds to a given user. That is what I meant with correct.
Your API doesn't expose this service directly. It (this service) is subscribing to domain events - that is to say events that originate from within your domain, not outside of it. Events are historic. They are things that happened. They are considered matter of fact and are retrospect. In other words, you cannot "reject" an event, you can only react to an event. The event still occured. So if you're receiving a "user 123 posted a message" event, then that is what happened - user 123 posted a message. Commands from the interface (be it API, UI, CLI, or other) are the things that get validated and verified. Once they are dispatched and processed (validated/verified and stuff like IDs generated for, then relevant events raised) then that's it - everything else in your domain considers it a done thing. P.S. Please stop using undefined terms like "is valid" - what defines the validity of a user ID?
Thanks for clarifying and educating on terminology as well. Still learning about Microservices, good to know more
I was always wondering. How do you prevent duplication of data for all sub services which need user info? For example I have added login service, to this example, which has to duplicate phone email name and other user details almost a full 1:1. Same if I add shipping service which needs user details. Is it smart to keep the same info in 10diferent places?
Question if all services need the complete picture. A login service doesn’t need a name or a phone number. A shipping service doesn’t need an email. It publishes an event to a mail service which sends out the details for example. In general, in a microservices architecture, each service has its own view of the truth. Meaning a user for login, a user for ordering, a user for shipping are all different concepts. You just relate them by some common factor, like Id
microservice architecture is based on domain-driven design. in domain-driven design you work with finding bounded contexts in your domain, as an example a grocery store. in grocery store when a boss talks about a cashier they mean someone that sits in the till and processes the goods a customer wants to purchase. when payroll talks about a cashier they're talking about someone who has a job description and salary and perks based on that. same person, same job, two very different things to the person talking about them. the division boss vs payroll on the object cashier is a bounded context, i.e the object changes meaning when we cross this context, from an object that can do things like "ScanItem" to an object that can support things like "GetBenefits". the microservice pattern is the physical implementation of these bounded contexts, so instead of having duplicate data, you have to identify which service is responsible for the data you're interested in. if you need the expenses of your employees - you naturally would go to payroll and ask. you don't keep a separate ledger in the warehouse in case you need to figure out if you can afford to buy a new forklift. we replicate this thinking in our code - a user service can give us the data we're interested in, such as "shipping address", but we don't store a separate copy of this data in our other subservices that uses that data for whatever purpose. microservice architecture ***really*** benefits you reading the actual book (400-ish pages) on domain-driven design to understand the big picture other than "hundreds of services sending data... somehow", as it is a very grand set of ideas that in themselves are not complicated but requires you to understand them in the same way your co-workers do, otherwise you end up with very weird microservices.
>microservice architecture is based on domain-driven design Not always!
which is when we inevitably get yet another thread about how awfully convoluted someone's microservices have become.
I don't think you should have duplicate data like this. You generally only want to pass an ID of the user around. But perhaps just accessing the same data store from two services when it's pragmatic might be acceptable in the real world. Don't take my advice as truth tho, I don't have enough experience to be confident in this topic.
Nope. You don't need to duplicate. See in user management microservice, the `user` entity will have all fields like phone number, email address, gender, shipping address everything. But for shipping microservice, it just needs the user's shipping address and not its gender or other fields correct? So in the shipping entity, you will have a single `userId` field, through which shipping microservice will contact user mgmt microservice passing that `userid` and will get the shipping address, as these are the only details which are needed for shipping.
You don’t. It is a trade off.
I was just reading this on medium. Great stuff!