CODEWITHSUNDEEP
design-patternsservicearchitecturemicroservices
Crooked Hillary
Crooked Hillary

Reputation: 11

Does microservice data "ownership" mean data "understanding"?

Let's say the "whole picture" of a business entity is like

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5,
   bar: "something",
   baz: [1.0, -4.3]
}

but for whatever reason we've decided that there should be a foo service, bar service and baz service that own respective pieces of data in a way like

{
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   foo: 5   
}

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   bar: "something"
}

{ 
   id: "117ed0fd-2546-4775-8ab6-d7671694d410",
   baz: [1.0, -4.304]
}

However, let's say what I notice about the system is that

Would you say this is design smell?

Upvotes: 1

Views: 754

Answers (3)

Arnon Rotem-Gal-Oz
Arnon Rotem-Gal-Oz

Reputation: 25909

That's very little context :) but as written it does seem like the services are overly coupled because they all need all the data from each other.

Note that a service doesn't need to be ignorant of other service's data. In fact, it is rare that services are completely independent of each other - the business value usually happens on the interactions e.g. for a catalog the item description might come from one service, the base price might come from another service and these only care about the item id but the custom price for a specific customer will depend on data from the base price and customer attributes and the service that calculate the custom price needs to understand the data from the two services it consumes.

Services should be owners (responsible for the creation, source of truth) for some information. Other services (and clients) should use that info - but again if it is all interdependent than that's probably too coupled

Upvotes: 1

guillaume31
guillaume31

Reputation: 14064

It's perfectly OK for microservices to capture, store and reason about bits of data originating from other services.

Just because each microservice has its own canonical model doesn't mean it can't import concepts defined elsewhere or redefine them in its own terms.

Eric Evans has this great presentation about Bounded Contexts/Microservices that shows you how vast the array of integration options can be.

Upvotes: 0

ManuPK
ManuPK

Reputation: 11829

First of all, if you choose a microservices architecture, you will need to prepared to take lot of overhead on orchestrating the services, drawing the right boundaries and establishing each service has less or no dependancy on each other. Read and understand a bit more on characteristics of microservices..

So, coming to your question, if you have 3 services and they need each other to make sense of the data it is returning, probably you are having a design smell. It is going to be very difficult to maintain such an architecture as change to one may cause issues to another service extra. Even in the same application you would'nt want to split to 3 services just for the sake of doing it unless there is any significant benefit.

Upvotes: 1

Related Questions