Return value from command handlers

[Marijn Huizendveld]

Hi everyone,

Say my Aggregate is returning a ValueObject or DTO when calling a behavioral method. Would you consider returning this value from the command handler to the client code (e.g. a Controller class of some sorts)?

Thanks,

Marijn

[@yreynhout]

That would violate CQS ergo CARS, I mean CQRS. There's always Mediator or PubSub or DomainEvents or ...

[jdn]

Of course, it depends on whether you count on violating things.

I return values from command handlers at times, but otherwise generally follow the tenets of what various people at various times and in various ways call CQRS, so whether I'm "really" doing CQRS or not doesn't concern me much.

YMMV.

jdn

[Greg Young]

What is being returned and why? There are other ways of handling it. 

Of course its not that hard to do. A command handler would just become

F(T) -> object where T:Command

then you create a class called Unit that represents "Nothing". If its nothing return nothing else return whatever you have.

Cheers,

Greg

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.
To unsubscribe from this group, send email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Le doute n'est pas une condition agréable, mais la certitude est absurde.

[jdn]

Obviously, there are many different ways of handling it.  I happen to have two types of command handlers, ICommandHandler<T>  and ICommandHandler<T, TReturnValue>.  Hadn't thought of just having the one type of handler and return null (normal case) or return something not null. 

The "why" of returning values is the more interesting question.  The short answer is very uninteresting, "sometimes it makes sense."

jdn

[Marijn Huizendveld]

On Jan 28, 2013, at 7:57 PM, @yreynhout wrote:

> That would violate CQS ergo CARS, I mean CQRS. There's always Mediator or PubSub or DomainEvents or ...

Sometimes I forget what I've learned along the way, this question is an example of that happening. Reviewing my codebase there is really only one example where it eases things a lot however. That's a situation where one aggregate is responsible for Issuing a unique code from a list. It's nice to trick the user into thinking that everything has been updated already even though our events are still being consumed by the different projectors and handlers. In that case I would like to return the code that was the result of the operation. Now, you might be arguing that I should look in the list of recorded events and obtain the code from there but I doubt that will make the code easy to read. On the other hand, returning values of aggregates through a thick layer of CommandHandler decorators is not really elegant either.

[Marijn Huizendveld]

On Jan 28, 2013, at 8:00 PM, jdn wrote:

> Of course, it depends on whether you count on violating things.

It's my goal to be pragmatic when it makes sense to do so :-)

> I return values from command handlers at times, but otherwise generally follow the tenets of what various people at various times and in various ways call CQRS, so whether I'm "really" doing CQRS or not doesn't concern me much.

Are your command handlers being decorated? I'm wondering if it really makes sense for decorators to be aware of the fact that a command handler _might_ return a value. Since in nearly all cases I shy away from it, I want to return data only in the few occasions where tricking the user is important.

[Marijn Huizendveld]

On Jan 28, 2013, at 11:19 PM, Greg Young wrote:

> What is being returned and why? There are other ways of handling it.
>
> Of course its not that hard to do. A command handler would just become
>
> F(T) -> object where T:Command
>
> then you create a class called Unit that represents "Nothing". If its nothing return nothing else return whatever you have.

If only PHP had syntactic awesomeness :-)

>
> Cheers,
>
> Greg

[jdn]

As I mentioned, I have different interfaces for when they return something vs not.

[@yreynhout]

Why not hand the code along with the command?

[marijn.hu...@gmail.com]

Time to pick up an old thread. 

I'm thinking that when all you need to know is the data than you probably should pass it along. 

Today I was thinking though that one may want to return the event stream that has been recorded.

Has anyone tried that? What are your experiences with doing so?

Currently we have a huge amount of exception misuses for things that ought to be events for the simple reason of flow control in the client code.

By returning event streams from aggregate command methods and the command handlers themselves I can easily read the "things that happened" as a result of my command.

It would also allow for much simpler event metadata recording by using command handler wrapping.

Basically all I see right now are advantages so I must be missing something. 

I look forward to hearing from you :-)

[Greg Young]

Synchronous clients. Synchronous Apis.

They have value at times especially in line of business systems.

--
You received this message because you are subscribed to the Google Groups "DDD/CQRS" group.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Studying for the Turing test

[marijn.hu...@gmail.com]

Well I'm not processing my command async at the moment and I'm not sure I will anytime soon.

But I suppose it won't scale well. 

Synchronous clients. Synchronous Apis.

To unsubscribe from this group and stop receiving emails from it, send an email to dddcqrs+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Kasey Speakman]

I'm doing something like this in the latest project. It's my custom unit of work that I call EventStream. My event-sourced aggregates expect to use EventStream for replay and when applying events.

call persistence handler

    load stream

    call command handler

        instantiate aggregate / replay stream

        load needed resources

        run behavior

    save stream.uncommitted

[@yreynhout]

"Currently we have a huge amount of exception misuses for things that ought to be events for the simple reason of flow control in the client code."

What is meant by "client code"? What kind of flow control are we talking about? Domain flow or UI flow?