Hi Chris,
Let me start by saying that I am not a DDD expert; I have had a couple of tries at DDD apps, and I know for a fact that I have a lot of improvement to do.
With that in mind, and rearranging your text a bit:
> But in an already well-factored Domain, implementing this pattern seems to cause code duplication for little tangible benefit. A well-designed Domain will already include Domain Services that succinctly address a given use-case, composing and calling multiple Domain objects as needed, and returning the result/s needed for that use-case.
> ...
> Because I usually need the Domain Service available for use by other Domain Services, I want it to return Domain Objects.
You're right that the Domain Services should be dealing only in domain objects, not in Payloads. Payloads are (AFAICT) strictly to be used to the code that called the domain in the first place. So I would emit Payloads only at the boundary, never passing them around inside the domain at all.
> Having an extra "Application Service" on the Domain boundary to simply invoke this underlying Domain Service and return a Payload ... seems counter to DRY.
Maybe; then again, maybe not. I share Matthias Verraes' opinion about DRY: <
http://verraes.net/2014/08/dry-is-about-knowledge/>
Now, if the Application Service and the Domain Service it calls both have to change in concert, then I think that invokes DRY. However, if some Domain Services are always called only by the UI, then perhaps they are really Application Services after all.
> By calling it indirectly via an "Application Service", I end up with a proxy method for *every* Domain Service I need to expose to my UI layer. These proxy methods do nothing by wrap the forwarded method's result in a Payload. In my application this will be literally hundreds of methods.
For me, the key benefit of the Payload is that it allows your Domain to explicitly state "what happened" inside the domain. For example, merely returning a domain object doesn't tell the calling code much; it usually has to inspect that object to figure out what to do. That probably means the calling code has to know "too much" about the domain. With a Payload, you can send back not only the domain object(s), but a status and messages *about* the domain objects. The calling code can use that information to reduce its own inspection logic when building the presentation.
So it's entirely possible that in your situation, a Domain Payload proper is not really necessary. If your domain objects already carry all the information the UI needs to figure out what to do with them, or if there's no figuring-out needed at the UI level, then yeah, a Application Service that returns a Domain Payload might be overkill for you.
Does that begin to help? (I know that was a long way to say "it depends" but I hope it helps show what the "depends" are. ;-)
--
Paul M. Jones
http://paul-m-jones.com