where to discern what action occurred

[Raif Harik]

Hi,

Given a UI that is not a granular and intention revealing as you would like, there are a couple of options.

One is to just make big fat commands and events.  Another is to try and parse the incoming data and make assumptions.  e.g. if a user comes in with an id you can presume that you are updating a user, if not you can presume it is a createNewUser situation.  That's a super simple and not that interesting example, but other such as address.  how many characters over all have changed, if it's like 3 (arbitrary) or less you could assume it's a fixAddressTypo action.  more than that i could be a createNewAddress action.

So my question is, where is the best place to make these determinations?  In the API endpoint and make a corresponding command? or in the AggRoot and make corresponding events?

Thanks,

r

[Daniel Plainview]

Commands and events come from your business rules.

If you have poor CRUD-like API when client simply sends current state of the object, you can make some kind of bridge between this poor API and your commands.

Don't let your model/commands suffer from UI, i.e. don't make fat and generic commands like UpdateFoo.

Bear in mind, that such API may suffer from race conditions: if user A opens fat form, user B opens same form, user B changes something, user A changes something and saves the form, then you probably will make incorrect assumptions of user A intentions (it would look like user A wants to revert user's B changes).

It can be fixed with something like optimistic locking, but it's an UI issue in the first place.

Good UI should provide user intentions in explicit way: user wants to ChangeAddress, user wants to FixTypoInAddress, ~ to DeleteAccount, etc.

Client knows what user wants better than server.

[Raif Harik]

RIght, so do it in the API endpoint and emit the proper command. My concern is that it may be appropriate to emit more than one command as a result.  Which seems a bit odd.  The race condition is allso an issue but I think I"m ok in this case.

--
You received this message because you are subscribed to a topic in the Google Groups "DDD/CQRS" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/dddcqrs/Blyw9OAoJL4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to dddcqrs+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/dddcqrs.
For more options, visit https://groups.google.com/d/optout.

[Greg Young]

I moved once from 19d some street to 19c some street. I have also
moved from 2481 some street to 2479 some street

> --
> 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.

> Visit this group at https://groups.google.com/group/dddcqrs.
> For more options, visit https://groups.google.com/d/optout.

--
Studying for the Turing test

[Daniel Plainview]

If you have explicit UI buttons "I want to change address", "I want to fix a typo", you can handle it.

But I agree, this example is very odd.