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).
Question
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
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.
3
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.
4