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?)

  • 2
    @Robert Harvey removing "thanks" at the end - wow, now that's a really valuable edit! :) (sarcastic)
    – Prokurors
    Oct 25, 2016 at 11:53
  • Please read here and here. Oct 25, 2016 at 14:20

2 Answers 2


I would argue your requirement has nothing to do with DDD. DDD is about solving complex business rules in complex business domain. There are no business rules in requirement you are trying to implement.

In context of DDD, your requirement will be part of Application Services layer and not part of any of the bounded contexts in the domain layer. As such, no rules or practices of DDD should apply to it. So thinking about it as different bounded context doesn't make sense.

  • Ok, I get it that there might be functionality that is not about solving complex business rules. If I place it in Application Services layer, then how would it operate with data? Repositories are part of Application Core, but for this CRUD stuff it should probably operate with database directly (skipping all the DDD related stuff)?
    – Prokurors
    Oct 25, 2016 at 12:08
  • Ok, since there are no other candidates and your answer was helpful, I'll mark it as answer.
    – Prokurors
    Oct 26, 2016 at 8:18
  • @Euphoric I think you are mistakenly considering DDD as only a set of tactical patterns, while the strategic patterns are the most useful. Prokurors, you could have a Product management CRUD bounded context where you implement business logic using transaction scripts rather than a full-blown domain model. However, do not make bounded contexts overly segregated. BCs do have a cost (anti-corruption layer, data distribution, etc.) and the benefits of segregating into multiple BCs must outweight this cost.
    – plalx
    Oct 29, 2016 at 2:47

I don't have enough points to comment above, so have to comment here.

I would suggest that the process is not necessarily CRUD if there are other domain rules, validation and events that must be considered during the import / update of the price list items.

I have ended up here because I am also trying to determine where in my model an import of customer data should occur. I will go through my DDD aggregates to import this data, because my Aggregates ensure the integrity of the system, i.e. ensuring required properties are set, and any domain events are raised. If I were to circumvent the DDD aggregates and perform a basic CRUD on the persisted state of the Aggregates for example, I may introduce inconsistencies into the system.

You may also face this issue if you update your price list data directly, without going through your aggregates. For example, does your PriceListItem have required fields such as currency, value, exchangeRateApplied. What would happen if you imported some data which had no currency, or the value is outside some min/max bounds for your domain? Also, if you validated the data in your import routine then you now have 2 sets of validation to maintain, if your domain requires modification to accommodate changes in the business.

As it stands my consideration at the moment is to build an import service (WCF), which picks up records from a file system based queue, and calls my CQRS command handlers to process the imported data.

This way all interaction is through the aggregates, via my CQRS, ensuring the ultimate data is consistent and the system is always in a valid state.

  • I don't have enough points to comment above, so have to comment here Please do not misuse answers for comments. Those will get closed anyway ("not an answer"). It's not that hard to gain some reputation to comment.
    – Jan Doggen
    Dec 16, 2016 at 8:43
  • Thanks, good points! You're right that there are business rules... I was a bit blind taking a perspective from a import stand point, but PriceList object has business rules. The thing is that all those business rules/consistency checks are quite heavy overload (which would not be a problem in case if working with one or few business objects), but I guess this overhead is a lesser evil than risk of loosing model consistency
    – Prokurors
    Dec 16, 2016 at 9:43
  • I find DDD is a great methodology to force you to clearly think about your domain (seems obvious) but sometimes I find myself making assumptions and potentially choosing the easy path which inevitably is the wrong path. So think about your aggregates, rules, enforcing your model and the rest seems to sort itself out.Unless you can guarantee your imported data is valid, you need some form of anti-corruption layer going on, so I find it best to go through the aggregates. Best of luck. Dec 16, 2016 at 13:19
  • @JanDoggen I understand. I felt I had something valid to add to the conversation to help Prokurors out. I will get my reputation up ASAP. Dec 16, 2016 at 13:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.