I'm currently trying to build my first solution following DDD principles. Until recently everything was more or less clear, but now I have a task to import configuration data for my application and I am not sure what would be a best place to fit such a functionality...
I have a sales analysis application, and at some moments there is a need to renew price list data (add new/delist products, or update prices). So in one operation I would import price list data for all of the products.
I guess it could be treated as
Price list renewal bounded context It could have an aggregate
PriceListItem and could have a DomainService
PriceListRenewalService, but this seems to be an anemic model (because this bounded context is about data import only - so it turns out to be plain CRUD).
What would be correct way to model such a service (subdomain) and what would be a valid (according to DDD) place for such a service (Which layer? Should it have a Bounded Context or would it be ok that such a service works directly with database, since it's just a CRUD?)