Reputation: 13348
In a REST-based microservice architecture, what is the correct way to group related data under a single entity. For example, we may have a user service responsible for managing users. Additionally, we may have a service responsible for managing some kind of data stored for each of those users (let's assume for this example that we're talking about a user's items/inventory)
We could separate the inventory management service and use it for creating inventories for anything, so I would ideally not want the inventory management system to require users in order to function.
Is there a typical pattern to use that would provide the grouping I'm looking for (multiple inventory items to a single owner)? What would the rest endpoints look like to support such an architecture?
Upvotes: 2
Views: 889
Reputation: 1341
"Service" behaviors usually translate to Factory pattern implementations no matter the semantic.
Api Side:
POST: yourapi.com/v1/inventory/add/
DATA: {
userid: 1,
products: [
'Canned Chicken Gizzards',
'Snake Oil Extract',
'Evaporated Water'
]
}
Factory class side:
InventoryFactory->addProduct((object) product)
-- also have a method to add products under a user --
InventoryFactory->addProducts((array) products, userid)
Upvotes: 1
Reputation: 1151
I think there arn't any typical patterns. It depends on your business processes and relations between entities. But there are some general statements.
You may formally check most of these assertions against your solution.
Moreover, it's always possible to split some service into two new ones. But more effort you make during analysis stage the less likely you will need to split services one time.
Upvotes: 3