Re: Application Services and Framework Annotations

Hi Marcin,

I also agree that transaction management should be handled in 
Application Services, but in a framework agnostic way (if possible). 
This depends of course on the framework capabilities, the chosen 
architecture and the nature of the project.

When a project is based on the Hexagonal Architecture, the 
implementation of Application Services are agnostic of the delivery 
mechanism e.g. HTTP, SOAP, GUI. Similarly, I am skeptical on letting the 
Application Service (the Use Case boundary) be aware of persistence 
mechanism details e.g. that the Repository implementation read/writes to 
a relational database. How transactions will be managed if the 
implementation of RepositoryX writes to a relational database and 
RepositoryZ writes to a NoSQL database?

This article 
[http://www.sapiensworks.com/blog/post/2013/05/01/DDD-Persisting-Aggregate-Roots-In-A-Unit-Of-Work.aspx] 
explains how to manage transactions involving 2 aggregate roots that 
doesn't depend on a transactional storage.

So my assumption is that managing relational database transactions in an 
Application Service (implicitly through framework annotations or 
explicitly begining/commiting a transaction) is a pragmatic solution 
applicable to many cases, but it is not a MUST from the Domain-Driven 
Design point of view.

Cheers,

Nikos




On 10/07/2013 02:16 PM, Marcin Gryszko wrote:
> IMO Application Services are framework dependent, since they handle 
> issues like transaction management, authorization and so on.
>