I am trying to implement Microservice to understand the architecture and how communication works. Many articles state that Services should follow the Single Reponsibility Principle, but it's kinda hard to achieve. For example, I have to search Item and get all the information (including stock).

So I have two services:

  • An Item Service which deals with everything related to Item. It has sub-services like ItemSearchService, ItemCreationService, etc.
  • A Stock Service whose job is to update stock, get Stock information, etc.

Is it alright if I do:

  • A rest call to ItemSearchService.searchById()
    • This will get the information (not including stock information)
  • A rest call to StockService.getStockCount()
    • This will get stock information
    • Control is returned back to ItemSearchService, where the Stock Service information is aggregated, and search result is returned

My concern: Is it breaking the Single Responsibility Principle? Because search responsibility is just to search, and here it's getting the stock information also.

  • 4
    "Single Responsibility Principle" doesn't mean what you think it does. I suggest you come up with a sensible design, and then decide for yourself if each class is doing too much. – Robert Harvey Dec 18 '16 at 21:05
  • I will give a scenario using the Blizzard Rest API. You can grab all auction data in one swoop, but, to get all the information about each item, you need to lookup the item id inside their items api, and since some of the auctions are pets, you need to lookup using the pet id in the pet api (using the item id as pet id), to get the item id to lookup the item data to relate the two -- PITA -- given the service also has a limit on how many calls you can make, it is more logical to provide the resulting data from the query in a sensible and consolidated manner where reasonable. – Kraang Prime Dec 18 '16 at 22:08
  • 1
    Change SRP by "bounded context". SRP can be applied on different levels. In this case, the level higher than the one you are familia with (classes or functions). Think in business units, independent, working altogether for a higher level app. The more grained are these units the more complex is the implementation. – Laiv Dec 19 '16 at 12:00

The Single Responsibility Principle is widely misunderstood. It does not state that an object or service should "only do one thing". Rather, it states it should only have one "reason to change", where "reason to change" means business decision or technical issue which which would force you to change the code, or in this case, change the interface of the service.

So if you had a service called numberOfAvailableBlueCapsAtNewJerseyWarehouse() they you would break the SRP because this method would have to change if either the product item changes (e.g the caps are no longer available in blue) or the New Jersey warehouse is decommissioned. Therefore frequently changing factors like products and warehouses would be configured in data rather than hardcoded in a service interface.


I never actually heard SRP mentioned in context of micro-services before. It definitely does not need to be as draconic as it sounds, though. When you are writing MSE, you need to think what parts of the code can and should be coupled/scaled/deployed together? In your case, can Items exist without Stock? Does it give you benefits to separate them? Does it make sense in your domain to separate them or keep them apart?

Since you are writing concept code to feel out the architecture and how communication works, I say go nuts and refactor it as much as you want. This way you actually will have a feel for aspects like

  • moving complexity from code to environment
  • performance
  • data integrity
  • operations, dev-ops
  • managing the build pipeline


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.