Colin M
Colin M

Reputation: 13348

Grouping Data in Microservices

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

Answers (2)

Coldstar
Coldstar

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

Valentin P.
Valentin P.

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.

  1. 'Entity' services must be agnostic to all business processes.
  2. Functional context of 'Entity' services must not overlap.
  3. There should be no redundant logic in services implementations.
  4. No need to create new service for each entity if business processes don't require it.
  5. If there is a strong subordinate relation between entities, thus it's possible to introduce aggregate containing all tied entities and new service operating with it.

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

Related Questions