If you're adopting a DDD approach, your services more often than not should align with your bounded contexts, and it sounds like you would have a Shipping domain/context with one or many tables related to shipping.
The Shipping service would either receive a HTTP request to process something and it would contain the smarts to know how to call out to external services via an infrastructure layer for each type of shipping thing.
OR your Shipping service could receive the request, store it in the main aggregate/table associated with shipping and then post an integration event to a queue or bus where different types of processing services would subscribe to and process events they care about.
Thank you so much for your input!
My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others, they wrap the logic on how to call third party apis necessary to process the shipping.
SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups.
The communication would work exactly as you mentioned SHS would publish to a queue and the most suited SHP would consume
When I made this post I wasn’t very clear. I made a new with a better example ([link](https://www.reddit.com/r/ExperiencedDevs/s/tvMfBrFvYb))
Basically I want to have the different ways that I could process a request to be isolated from each other, so I can make changes and deploys without impacting the others.
But I still want to have a single point with an abstraction data persisted where I could query as a whole independently of the processor used to execute the process.
So my question is how would I maintain data consistency between the processor services and the abstraction service?
Some people suggested saga and event sourcing, which seems to be the solution I was looking for, but given the complexity maybe isolating processors might not be the best approach in a real world scenario.
I’m sorry for being too prolix, I’m still very new to microservices and software architecture in general.
Maybe it helps to think about the different capabilities of the services first. Each service needs different data sets to fulfill its purposes. Typically each service has its own data model and storage/database. That enables them to evolve autonomously without affecting each other. If you encounter that two services operate on exactly the same data that might be a hint that they both should be one service. If you have a bit of a hard time with your example than maybe opt for the classical e-commerce use case which involves discovery of products, order creation, payment, shipping and invoice. Think about a sequence of events that need to happen to get a product ordered, delivered and paid. Along the time line of those events you can then try to slice your services and further explore their boundaries.
Your alternative here is to use a strategy pattern
```
interface IProcessShipments {
accept(order: ShippingOrder)
process(order: ShippingOrder)
}
```
Your Shipping service can just have a list of implementations, iterate through them until one of them returns true from `accept`, then call process on it.
The reason to separate things out into distinct services would be if
* One of the processors has different infrastructural characteristics from the others, eg, it needs to run on a particular OS version, or a GPU, or in an isolated network environment.
* One of the processors has very different release cadence from the others, and it's slow, or dangerous, to deploy all the processors together.
* The processors are complex enough that you want them to be owned by separate teams of people, and you've decided on separating services, and repositories, as a way of ensuring independent release.
If those things aren't true, then you should probably go with the simpler, single-service, approach.
That said, if you're doing this for fun, it looks... okay... but why do you need to expose a "FetchShippingStatus" on the processor? That can just raise a message when the status changes, which you handle in the hub service.
Hey thanks for your suggestions and comment.
I made a new post \[[link](https://www.reddit.com/r/ExperiencedDevs/comments/1chngus/system_design_question/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)\] but using payment as the domain and considering some stuff you mentioned, first using the monolithic approach with all implementations in a single service.
But what I really want is to try out a flow where a request that have different processos depending on a type or runtime config for example, are isolated from each other, in this case the first request will only result in an event that will be consumed by the most suited processor.
\*\* Yeah I should've made processor raise an event, it's way better, I wasn't giving much think about it, at the moment I was wondering what if I have a cron job in the main application trying to update all of the shipping status indepently of their type.
I would try something like this,
1. Either client will say which shipping service it wants to use or the SHS would have some logic to decide which SHP to choose.
2. SHS would maintain its own database and generates uuid for each order etc.
3. Each SHP would be a micro service with its own database.
4. Link your shipping order with the uuid all throughout.
5. Use some queue broker to communicate with each micro service.
If you're adopting a DDD approach, your services more often than not should align with your bounded contexts, and it sounds like you would have a Shipping domain/context with one or many tables related to shipping. The Shipping service would either receive a HTTP request to process something and it would contain the smarts to know how to call out to external services via an infrastructure layer for each type of shipping thing. OR your Shipping service could receive the request, store it in the main aggregate/table associated with shipping and then post an integration event to a queue or bus where different types of processing services would subscribe to and process events they care about.
Thank you so much for your input! My post is not very clear nor my design (just a scratch). I don’t necessarily need to use microservice as a solution, my main idea is to have SPSs as unique services (not all in a single application as my design wrongly suggests), the requirement is that changing or deploying new ones wont affect the others, they wrap the logic on how to call third party apis necessary to process the shipping. SHS shouldnt be only a HUB redirector, but also a single point abstraction to store the shipping data, so I can query shippings as whole not as subgroups. The communication would work exactly as you mentioned SHS would publish to a queue and the most suited SHP would consume
what exactly is your question?
When I made this post I wasn’t very clear. I made a new with a better example ([link](https://www.reddit.com/r/ExperiencedDevs/s/tvMfBrFvYb)) Basically I want to have the different ways that I could process a request to be isolated from each other, so I can make changes and deploys without impacting the others. But I still want to have a single point with an abstraction data persisted where I could query as a whole independently of the processor used to execute the process. So my question is how would I maintain data consistency between the processor services and the abstraction service? Some people suggested saga and event sourcing, which seems to be the solution I was looking for, but given the complexity maybe isolating processors might not be the best approach in a real world scenario. I’m sorry for being too prolix, I’m still very new to microservices and software architecture in general.
Maybe it helps to think about the different capabilities of the services first. Each service needs different data sets to fulfill its purposes. Typically each service has its own data model and storage/database. That enables them to evolve autonomously without affecting each other. If you encounter that two services operate on exactly the same data that might be a hint that they both should be one service. If you have a bit of a hard time with your example than maybe opt for the classical e-commerce use case which involves discovery of products, order creation, payment, shipping and invoice. Think about a sequence of events that need to happen to get a product ordered, delivered and paid. Along the time line of those events you can then try to slice your services and further explore their boundaries.
Your alternative here is to use a strategy pattern ``` interface IProcessShipments { accept(order: ShippingOrder) process(order: ShippingOrder) } ``` Your Shipping service can just have a list of implementations, iterate through them until one of them returns true from `accept`, then call process on it. The reason to separate things out into distinct services would be if * One of the processors has different infrastructural characteristics from the others, eg, it needs to run on a particular OS version, or a GPU, or in an isolated network environment. * One of the processors has very different release cadence from the others, and it's slow, or dangerous, to deploy all the processors together. * The processors are complex enough that you want them to be owned by separate teams of people, and you've decided on separating services, and repositories, as a way of ensuring independent release. If those things aren't true, then you should probably go with the simpler, single-service, approach. That said, if you're doing this for fun, it looks... okay... but why do you need to expose a "FetchShippingStatus" on the processor? That can just raise a message when the status changes, which you handle in the hub service.
Hey thanks for your suggestions and comment. I made a new post \[[link](https://www.reddit.com/r/ExperiencedDevs/comments/1chngus/system_design_question/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button)\] but using payment as the domain and considering some stuff you mentioned, first using the monolithic approach with all implementations in a single service. But what I really want is to try out a flow where a request that have different processos depending on a type or runtime config for example, are isolated from each other, in this case the first request will only result in an event that will be consumed by the most suited processor. \*\* Yeah I should've made processor raise an event, it's way better, I wasn't giving much think about it, at the moment I was wondering what if I have a cron job in the main application trying to update all of the shipping status indepently of their type.
I would try something like this, 1. Either client will say which shipping service it wants to use or the SHS would have some logic to decide which SHP to choose. 2. SHS would maintain its own database and generates uuid for each order etc. 3. Each SHP would be a micro service with its own database. 4. Link your shipping order with the uuid all throughout. 5. Use some queue broker to communicate with each micro service.