hexagonal architecture and transactions concept

Question

I'm trying to get used to hexagonal architecture and can't get how to implement common practical problems, already realized with different approaches. I think my core problem is to understand level of responsibility extracted to adapter and ports.

Reading articles on the web it is ok with primitive examples like:

we have RepositoryInterface which can be implemented in mysql/txt/s3/nosql storage

or

we have NotificationSendingInterface and have email/sms/web push realizations

but those are very refined examples and simply interface/realization details separation.

In practice, however, coding service in domain model we usually know interface+realization guarantees more deeply.

For illustration purpose example I decided to ask about storage+transaction pair.

How transaction conception for storage should be implemented in hex architecture? Assume we have simple crud service interface inside domain level

StorageRepoInterface
   save(...)
   update(...)
   delete(...)
   get(...)

and we want some kind of transaction guarantee while working with those methods, e.g. delete+save in one transaction.

How it should be designed and implemented according to hex conception?

Is it should be implemented with some external coordination interface of TransactionalOperation? If yes, then in general, TransactionalOperation must know how to implement transaction guaranty working with all implementations of StorageRepoInterface(mb within additional transaction-oriented operation interface)

If no, then seems there should be explicit transaction guarantees from StorageRepoInterface in the domain level(inside hex) with additional methods?

Either way it is no look so "isolated and interfaced based" as stated.

Can someone point me how to change mindset correctly for such situations or where to read?

Thanks in advance.

score 2 · Accepted Answer · answered May 23 '20 at 18:17

In Hex Arch, driver ports are the API of the application, the use case boundary. Use cases are transactional. So you have to control the transactionality at the driver ports methods. You enclose every method in a transaction.

If you use Spring you could use declarative transaction (@Transactional annotation).

Another way is to explicity open a db transaction before the execution of the method, and to close (commit / rollback) it after the method.

A useful pattern for applying transactionality is the command bus, wrapping it with a decorator which enclose the command in a transaction.

Transactions are infraestructure, so you should have a driven port and an adapter implementing the port.

The implementation must use the same db context (entity manager) used by persistence adapters (repositories).

Vaughn Vernon talks about this topic in the "Managing transactions" section (pages 432-437) of his book "Implementing DDD".

Oh, escalating transaction up to api level seems legit in such concept. Seems I need to reed something more deeply then a brief overview of conceptions cause they usually very primitive. Thanks for the link, and i'll mark as answer cause got the answer, i was looking for! — recvfrom_ro, Nov 04 '20 at 22:48

hexagonal architecture and transactions concept

1 Answers1