Is it considered good practice to start a transaction in the "service/application" layer, and then have objects in the domain model make DAO calls which participate in that transaction?

  • I don't see how. Databases have the ability to process transactions that do not occur in the service layer. – Robert Harvey May 7 '16 at 6:18
  • @Robert: Thanks, but I didn't quite understand. What are you referring to when you say you don't see how, and I understand that databases don't care about application layers, so what did you mean when you say they can process transactions not occurring in the service layer? – Jon May 7 '16 at 6:37
  • As Ewan points out in his answer below, service layer calls depend on database transaction mechanisms to implement transactions. If your question is "should that be the case," my answer is "it doesn't matter, because that's how it works." – Robert Harvey May 7 '16 at 13:34

I assume you mean something like .nets TransactionScope.

Using(var t = new TransactionScope())
    DAL.Add(obj1) //dal automatically finds the transaction scope and enlists. Transaction created
    DAL.Remove(obj2) // sql executes in transaction
    t.Complete() //any db transactions are committed

While it is possible to use the transaction scope outside of your DAL and have everything work as expected, it relies on the underlying database connection library supporting TransactionScopes.

Since the purpose of the DAL is to abstract that underlying implementation from the calling code; your calling code cant rely on the DAL respecting the transaction scope.

Therefore I would say it is bad practice.


Beyond @Ewan's fine answer, to get more insight, we need to look more into what is suggested when saying: "service/application" layer.

The terminology of services, Services in Domain-Driven Design (DDD), is applicable to many things in DDD. However, the notion of a domain service, or by some, just service:

When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless. -- Eric Evans Domain-Driven Design

Domain services orchestrate collaborations that cross cut multiple domain objects. In doing so, they almost certainly require the use some form of transactional coordination among the domain objects.

Also, Can someone explain the difference between domain and application services:

Domain Services : Encapsulates business logic that doesn't naturally fit within a domain object, and are NOT typical CRUD operations - those would belong to a Repository

Again, domain services provide an interface to business operations, and implement business logic coordinating across CRUD operations of domain objects, and will certainly require some kind of transactional integrity.

Application services need to be distinguished from domain services. Application services, should not require access to domain object transactions. If domain objects individually don't provide the required functionality, then the necessary business logic to orchestrate them should be placed in a domain service near or with the domain objects.

Is it considered good practice to start a transaction in the "service/application" layer, and then have objects in the domain model make DAO calls which participate in that transaction?

It is not good practise to expose domain layer transactional implementation details (e.g. start transaction obtaining transaction id or object) to the application layer, which has application services.

It is necessary practise in maintaining integrity for the domain layer, which has domain services and domain objects, to have access to transactional capabilities, such as starting transactions.

If the application requires (transactional) coordination among domain objects, create a domain service to implement the business logic, and expose that thru a service interface.

  • Maybe full source code sample about Domain Services, Application Services, and Infrastructure Services in github – Kiquenet Aug 11 '16 at 8:25
  • But domain service is part of business layer and transactional integrity is part of infrastructure layer, so how this fit together, can you please provide simple example ? – Muflix May 4 '19 at 10:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.