4

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

Community
  • 1
  • 1
Lord Yggdrasill
  • 3,197
  • 4
  • 26
  • 42
  • The style of the application service operations is sometimes called "Transaction Script". Maybe this is less confusing with regards to the programming paradigm. – theDmi Oct 19 '15 at 10:32

2 Answers2

7

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.

guillaume31
  • 13,738
  • 1
  • 32
  • 51
0

All methods in the OO world are procedural :)

I think what the authors are trying to bring across is that an application service is implemented as operation script. So it simply coordinates the domain and various other bits of infrastructure as a sequential set of calls. Ideally transaction boundaries are also handled in the application service layer.

Perhaps Martin Fowler's service layer write-up will provide more information.

You may be confusing Structured Programming with Procedural code :)

Eben Roux
  • 12,983
  • 2
  • 27
  • 48
  • 3
    Well to me, a method that operates on the object's own data is not procedural, its exactly what an object is supposed to be, a combination of data and behavior. Its procedural if data and behaviors are separated, which is why Anemic Domain model is procedural and an antipattern. – Lord Yggdrasill Oct 17 '15 at 11:19
  • Semantics aside, application services are meant to be stateless so the requisite data is passed in to the relevant method call and any additional data is obtained by the method. After that the various calls are made. I'm afraid that there is no way to make it more OO than that. Any code that can be moved into a class should be but as the application layer is somewhat of an integration layer any class that represents that layer will appear to be procedural. – Eben Roux Oct 19 '15 at 04:25