Using your answer regarding Sangwoon Park's comment as a starting point:

I don't get how "managing transactions at the repository level" is a viable solution?

In your implementation, if we look at the method AddToCartService.addToCart(), this method never decrements the "itemsInStock" of the product you fetch from the DB. A correct implementation should most likely:

1. fetch the product by id and "lock" it to prevent other requests from reading it
2. add a certain quantity to the cart
3. DECREMENT the number of itemsInStock of the product by the given quantity
4. save the product
5. save the cart

All this should obviously happen in a transaction so that no one else can read the itemsInStock of the same product while we're updating it.

With that in mind, I'd be curious to see how you can make it work with transaction managed at the repository level. In any cases, I'd be curious to see how you'd manage transaction in general in a hexagonal architecture. That's probably the one aspect I'm missing in this high-quality blog post.

Hi Sven,
I like the fourth approach best at the moment.
Do the application services belong to the infrastructure hexagon, which allows me to use @Transactional annotations?

And one more question..
What do you think about the following approach?
i.e., abstracting the transaction operation as a outbound port and using it inside the domain service?

e.g.,
someDomainServiceFunction() {
try {
transactionPort.begin();
...
transactionPort.commit();
} catch (...) {
transactionPort.rollback();
}
}

or

someDomainServiceFunction() {
transactionPort.execute(() -> {
...
});
}

Thanks again for the great article!

Hi Sangwoon,

that is indeed a very good question, and I could write a whole article on this topic (maybe I will).

There are different approaches to this:

* You can make the application core transaction-aware and annotate your services with @Transactional (this has the disadvantage of bringing technological aspects into the core).

* You can manage the transactions at repository level (as I have done).

* You can combine your entities into aggregates according to domain-driven design and save and load entire aggregates transactionally at repository level.

* According with Domain-Driven Design, you can place application services on top of the domain services to manage the transactions.

* And more...

The hexagonal architecture does not make any specifications in this regard. I suggest you experiment with different variants and analyze which one is best suited for your application.

Best wishes
Sven

We also need to recreate the Jakarta EE exception handling mechanism, as there is nothing comparable in Spring as far as I know. Please correct me via the comment function if I’m wrong!

Spring now provides "ProblemDetails" class to wrap the details of the issue. If I understood the statement correctly, ProblemDetails could save you. If not, sorry for the confusion.