I have a root aggregate Orders. Orders have line items. I have a repository of type IOrderRepository, which has methods like GetOrderName, GetAllOrdersItems, AddLineItem, RemoveLineItem, CountOrderItems.
Let's say I am using SQL. I use 2 tables - Orders and OrderItems. For some reason, let's assume I decide to have a field order_item_count on Orders. Whenever the user adds or removes a line item we update this count. Therefore I need to have this count updated atomically at the same time we add or remove a line item.
This means I should use transactions - I want my persistence to be such that if I update one table I update both tables (we don't want a line item to be added to OrderItems but a concurrent request also removes LineItems and the Order table count field to be wrong). But how does this fit into the services, repositories and aggregates setup. My feeling is that it shouldn't touch the aggregates (domain), as that breaks the idea of persistence ignorance. Should it be in the services*. Would the service be responsible for injecting a database transaction object into into my implementation of IOrderRepository, call it OrderSQLRepository
If it's in the services that means the services needs to know details about the domain, such as when we should construct an OrderSQLRepository with a transactions and when it should not. Cases where we might not want to use a transaction is when the domain is just going to call IOrdersRepository.GetAllOrdersItems IOrdersRepository.GetOrderName.
If we started using a noSQL database and use OrderNoSQLRepository where there is only the Order table and OrderItems is now just a document on the Order tables, is it correct that the service application would know that we don't need to use transactions here.
Thank you
FYI, I read How handle database Transactions in DDD if Repositories need handle more than one table for get or persist a Domain Model? which was helpful, but I still have remaining questions
- and if so domain or application services
