Reputation: 13
I have a two-layer application which has the bottom layer for collecting data from external APIs and adding it to database and the second layer is for return data from database that is based on the data that I collected from the external API calls. so I managed to put the external API calls in the infrastructure repositories with their interface in the domain. So generally where I'm exactly stuck is to save this data that I'm collecting in database without creating a model for this data in the domain since this data is dependable on the external API I want to have this two layers totally separated collecting the data and return the other data without breaking the principles of domain-driven-design.
Upvotes: 0
Views: 2332
Reputation: 1937
What I will try to answer here is how DDD could help and highlight that the import is an implementation detail after you applied some DDD principle to find a useful design and an appropriated implementation.
So you need data for your App/Bounded context which will have to generate statistics (if you can put more business language here DDD will be even more helpful). What is the business use of this app ? what are the languages (Ubiquitous Language) and boundaries (BC) ? How is it going to interop with others contexts (Context Mapping).
You will need implement this model, and here you could use the concepts defined and define a persistence model (potentially the language used in the API isn't the language used by your app) and also you might need some validations and business rules during the import of the data. Because you might define Aggregates that ensure the integrity of the system, well here I am speculating. But this is a scenario how I would applied DDD and to make the point that we cannot apply DDD to import. But import is potentially an implementation detail.
Upvotes: 1