How do you handle shared concepts in a microservice architecture?

Question

I am researching architectural patterns for an application I'm developing and a microservice approach seems like it would be a good choice but I am not sure how to handle interactions between the services.

The application primarily deals with users, profiles owned by users, photos, and tags that represent one to many profiles in a photo. There would conceivably be methods to return photos uploaded by a user, return photos that contain a certain tagged profile, etc.

This is my first stab at designing a microservice-based architecture and I come from a monolithic-esque domain model inspired history. In that world, controllers would stitch these domain objects together but I am having trouble wrapping my head around how this would work in a microservcey way.

Answer 1

Usually, services call other services when they need to access their data. Each piece of data should belong to a particular service which will be the only entry point to accessing this data and modifying it. Some services will be simple and usually correspond closely to your domain model (e.g. a service for handling users) while others will be high-level and use data from other services (e.g. displaying a list of photos together with information about the users who uploaded them).

In your use case, you should start from the outside and think of what operations you want to make available to your user via an API (if it's a backend service) or what operations should be available in the GUI if it's a web application. Note that the GUI part is often a regular application with its own controllers: operations may be called via REST (like in AngularJS), but these endpoints are desinged only for the GUI application's use and are not microservices in the common sense.

Suppose you want to display photos together with information about uploaders. You could have a user service that returns information about a user given the user's ID and a photo service which can list photos (e.g. by searching by some criteria). The list of photos would contain for each photo the ID of the uploading user. This way these two services are not coupled - the photo service only knows about user IDs but nothing about the user data themselves. On top of these two services you could create a third service with an operation such as "list photos with information about uploaders" which would call the two other services and combine the data they return. Alternatively, this operation could be performed by your web application instead of a service.

Answer 2

The application primarily deals with users, profiles owned by users, photos, and tags that represent one to many profiles in a photo. There would conceivably be methods to return photos uploaded by a user, return photos that contain a certain tagged profile, etc.

Well, profile service should not work with user object. It may know only the ID of the user for which it is asked to return data, no more. This way you will not require interaction between user service and profile service.

If that doesn't answer your question, could you please clarify it by describing the exact situation you are dealing with?