Refactoring to Application Services w Payload

82 views
Skip to first unread message

Chris Domigan

unread,
Mar 25, 2016, 10:48:39 AM3/25/16
to The Aura Project for PHP
I am attempting to refactor an application to make use of the concept of a Domain Payload, as implemented in Aura Payload. The idea of it appeals to me, however there are some barriers I am running in to that are making me question the pattern as a whole, or at least my ability to apply it correctly. 

I understand the concept: Payloads are used on the Domain boundary to return one or more Domain objects to the User Interface layer.

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. Having an extra "Application Service" on the Domain boundary to simply invoke this underlying Domain Service and return a Payload... seems counter to DRY. 

Because I usually need the Domain Service available for use by other Domain Services, I want it to return Domain Objects. 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.

What luck have others had implementing this pattern into a large codebase / DDD application?

Chris

Paul Jones

unread,
Mar 25, 2016, 11:08:43 AM3/25/16
to aur...@googlegroups.com
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




Chris Domigan

unread,
Mar 26, 2016, 8:44:41 AM3/26/16
to The Aura Project for PHP
Thanks Paul, your comments make me think this may be a pattern my application can do without for time being. Appreciate you breaking down the "it depends" for me :)

Oh and by the way, I am absolutely loving implementing ADR. The Input - Domain - Responder tuple in Arbiter is so awesome how it forces me to leave logic out of my Actions and put it where it belongs.

Thanks again!

Paul Jones

unread,
Mar 26, 2016, 9:26:24 AM3/26/16
to aur...@googlegroups.com

> On Mar 26, 2016, at 03:12, Chris Domigan <cdom...@gmail.com> wrote:
>
> Thanks Paul, your comments make me think this may be a pattern my application can do without for time being. Appreciate you breaking down the "it depends" for me :)
>
> Oh and by the way, I am absolutely loving implementing ADR. The Input - Domain - Responder tuple in Arbiter is so awesome how it forces me to leave logic out of my Actions and put it where it belongs.

Ah, that's good news to hear. Glad to be of assistance!

Andrew Shell

unread,
Mar 26, 2016, 9:39:26 AM3/26/16
to aur...@googlegroups.com
Not sure if this is helpful but I gave a talk about this recently. I
discuss Uncle Bob's clean architecture, how domain and delivery layers
interact and show how I'd implement it in Radar.

http://youtu.be/yEc48QfkFcY

Cheers,
Andrew Shell
> --
> You received this message because you are subscribed to the Google Groups
> "The Aura Project for PHP" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to auraphp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Chris Domigan

unread,
Mar 29, 2016, 10:34:44 AM3/29/16
to The Aura Project for PHP
Thanks Andrew, have added this to my bookmarks to catch up on soon!

Cheers
Reply all
Reply to author
Forward
0 new messages