DDD: what are the OOP alternatives for procedural Application Services?

Question

I recently got a book Patterns, Principles and Practices of Domain-Driven Design by Scott Miller and Nick Tune. It has some nice examples in C#, so a bit different from the other DDD books I read before which was in Java. The Domain event implementation is very neat due to C#'s support for delegate and event.

However, there is one thing that worries me, as the book stated in the chapter of application service that it should be 'procedural in style and thin'. I understand that application layer is meant to be thin, but why procedural in style? I dont want to write procedural code, or I wouldnt have chosen DDD in the first place. I also found that this stackoverflow article also labels Application Services are procedural code:

https://softwareengineering.stackexchange.com/questions/279369/conceptual-mismatch-between-ddd-application-services-and-rest-api

So you see? Application services are procedural in style, and not OOP. This makes me wonder whether I can improve the design to be more OO by replacing application service's procedural interface by an OO interface. This article suggests that method objects will do, and does it work? What are the more OO alternatives to procedural application services? Can anyone elaborate?

http://ayende.com/blog/2145/entities-services-and-what-goes-between-them

Answer 1

An application service is not procedural in the programming paradigm sense of the term. It's an object that encapsulates data (references to its collaborator objects) and behavior -- coordinating calls to these collaborators.

It might look procedural in spirit because there's a sequence of actions, but when there's an applicative task implying a number of steps such as :

• get a domain object from a repository
• call a method on that object
• save the object

you can't escape that procedural/sequential nature, no matter the programming paradigm.

Even if you're using an object oriented Chain of Responsibility pattern for instance, with each step being carried out by a separate actor in the chain, you still need to have a "master" object that knows how to assemble the chain in the right order, thus by definition knows the procedure, so it's equally procedural.