1

I always encourage to design each service without knowing other services exists (isolated).

Few days ago, i was reading about the cons and pros of choreography over orchestration in micro service architecture, i came across this topic that, Lets say we have a system which consist of 3 services: ordering, payment, shipment. if i use a orchestrator, the orchestrator knows when and how to call each service. in fact its duty is to know how and when call what service, but in choreography, i have no idea when payment service does not know the ordering service exists how its gonna subscribe to its event (for sure at least ordering system needs to have payment models)?

i become more confuse when i start to think that, if we have a method in ordering service which returns the ordering information followed by payment data and shipping data. how its going to return payment and shipping data?

Behzad
  • 857
  • 1
  • 8
  • 27

1 Answers1

1

when payment service does not know the ordering service exists how its gonna subscribe to its event (for sure at least ordering system needs to have payment models)?

It is OK that a service knows about another service if the business purpose requires it. Just make sure you don't muddle the purposes and ensure independent development processes for either service, e.g. version your APIs correctly and have policies for obsoleting. Google goes as far as imposing internal charges for service usage between teams.

It is also allowed to have code libraries that are used by both services, as long as you treat these library dependencies like you would treat 3rd party libraries.

how its going to return payment and shipping data?

Depending on the complexity of the aggregation process you can have either a 3rd service which is responsible for the business scope that relies on payment- and shipping-services, or you have a dedicated aggregator component that will allow to merge/split requests from the front end (sometimes implemented as part of an API Gateway). If your aggregation logic is complex, create a dedicated service, otherwise you can use a generic aggregator.

Oswin Noetzelmann
  • 9,166
  • 1
  • 33
  • 46
  • so dont you think that the aggregator acts as an orchestrator? – Behzad Mar 13 '18 at 12:33
  • Yes, I'm just using "aggregator" as a term for a component whose purpose is simply combining/splitting service calls in a generic way (some people may call this orchestration, too). As opposed to a more complex orchestration service that applies certain domain logic while calling other services (business purpose bound, clear hierarchy of services). – Oswin Noetzelmann Mar 13 '18 at 22:40