I have to design a software using asp .net core which collects data from various datasources (s. picture below). E.g. DataSource1 and DataSource2 are including product data like attributes. DataSource 3 is including the assets of those products. I thought first of all I will collect the data from each datasource and persists them in own datasource with the defined entity below. I have the advantage later at translating or tranforming the data to use one abstract entity.
My question which pattern should be good for this system? Repository, Pipeline,...?? Could you show me some pseudo code?
What about DI if I use interfaces but should have multiplied instances of datasources?
A pattern (or a set of patterns) should be applied to solve a specific problem/complexity.
I think the pattern the pattern you need here is Facade.
The problem that it will solve is that it will hide the complexity of the 'three data sources' for your client.
Within the Facade you would merge the data into a reasonable entity.
Additionally, you could make use of the Proxy pattern, which could give you the 'cache' functionality for the 'merged' entities, which could solve the second complexity you describe.
I am not sure I understand the idea of persisting these items into a fourth datastore, that might be an overkill - but in any case, that can also be achieved with the proxy class - it's just that the cache would be more permanent - if your domain 'allows' it.
As for Repository (pattern) - well, I believe that it's very likely that any reasonable solution that you apply that will hide the details of your data access will end up to be a an implementation of a Repository.
I wouldn't be too strict about naming the patterns and sticking to sample code in books or articles. Patterns are high level guidelines that can be adjusted to needs.