j0nny, pelo que sei do assunto, quem deveria gerenciar seu controle transacional seria sua camada de aplicação:
[quote]The application layer is responsible for driving the workflow of the application, matching the use cases at hand. These operatios are interface-independent and can be both synchronous or message-driven. This layer is well suited for spanning transactions, high-level logging and security.
The application layer is thin in terms of domain logic - it merely coordinates the domain layer objects to perform the actual work.
http://dddsample.sourceforge.net/architecture.html[/quote]
[quote]The application services in the sample application are responsible for driving workflow and coordinating transaction management (by use of the declarative transaction management support in Spring). They also provide a high-level abstraction for clients to use when interacting with the domain. These services are typically designed to define or support specific use cases. See BookingService or HandlingEventService.
In some situations, e.g. when dealing with graphs of lazy-loaded domain objects or when passing services’ return values over network boundaries, the services are wrapped in facades. The facades handle ORM session management issues and/or convert the domain objects to more portable Data Transfer Objects) that can be tailored to specific use cases. In that case, we consider the DTO-serializing facade part of the interfaces layer. See BookingServiceFacade for an example.[/quote]
Como citado acima, seria um service, mas não um Domain Service, e sim um Application Service.
Acredito que essa seja uma saída válida, por exemplo, se em algum cenário você tivesse que alterar dois Aggregates diferentes em uma mesma transação.
