How handle Transactions with DDD and Repository Pattern?

Question

I am refactoring a project to bring it closer to DDD. The project is written in VB.Net and use WinForms to UI. I have been learning about DDD and I still don't have some things very clear.

I use the repository pattern and SqlKata to create and execute SQL Sentences. I read about why transactions should be handle in Application Services, but I think about some cases which to handle transaction in repositories could be a good idea. An example:

A domain model Order with a list property Lines . A service called FindOrderService . The service use the OrderRepository and its function .FindById(...) . This repository return Order with its Lines . In Database Order and OrderLines are two different tables.

I. Shouldn't the repository function handle a transaction by having to use two tables to make sure the domain object is created in a consistent state? With a function .Add(...) Wouldn't the same thing happen?

II. Application services may or may not be used in a transactional manner. But they don't know how many tables are used to persist an Aggregate. Wouldn't ensuring something like this be a matter of Infrastructure even though it can also be handled from the application services?

III. From what I've read. It seems that exist two terms: "Bussines transaction" and "Technical transaction" (in this post ). Are this exaples technical transactions?

Thanks in advance!

Answer 1

I read about why transactions should be handle in Application Services, but I think about some cases which to handle transaction in repositories could be a good idea.

The fact that a specific scenario allows to have things done in two different ways does not mean we should choose the "rule breaker" way: having a single repository in the context of a transaction does not justify making the repository own the transaction. A transaction should span over one or more repositories by design.

I . A transaction can be abstracted away in application level, yet "contain" a single repository that queries/updates two tables in order to keep consistency.

II . Transactions, repositories, aggregates - all of them should be abstracted away in application level. True, infrastructure level is where you create concrete implementations (technical transaction, several tables, some entities), but application does not care that a single unit-of-work (transaction) spans over four repositories which actually "hide" eight tables.

III . Business transaction and technical transaction can overlap, but don't have to. For example, you can have a business process within which multiple technical transactions are executed (a single process may operate on different databases), composing together a single business transaction.