Reputation: 3
I have the following scenario:
You can create an application via application-service. Before the application can be created specific information need to be checked. This information are distributed and only accessible via user-service and product-service.
First idea would be to send a message through all services via service bus and extend it by all necessary data and process the data at the end again in the application service:
->Application-service->User-service->Product-service->Applicaton-service
Second idea would be to store all relevant data redundant in all services. Means the application service has a copy of the user and product data.
Both ideas don´t feel right.
Are there any better approaches?
Upvotes: 0
Views: 188
Reputation: 380
In service-oriented architecture like you are describing, it is perfectly normal to have data replicated in multiple services, with each extending the core entity specific to that service.
I suggest reconsidering your service boundaries, though. A service is the technical authority for a specific business process. Services are not meant to be aligned with business data.
For example, your Product Service
and User Service
sound like business data, and the Application-Service
sounds too broad, without knowing more information.
Consider an Order-Service
that needs information about the products. It may subscribe to ProductCreated
events from the Product-Service
to populate itself with product information, although likely just a ProductID. The Order-Service
does not need to know the product's name, description, price (this may live in the Billing
service), etc.
Since a service is the one and only authority for a business process, it therefore should also own the user interface. Composite UI patterns allow rending a single page with components from multiple services. The Application-Service
would host the page and the glue that pulls the components together. For more information on that, I found Micro Frontends a good read.
Upvotes: 3