What of Flux ?

[Douglas Gugino]

Wondering others thoughts on this ... especially the comment that "Actions are exactly the same as Domain Events" ... thanks in advance.

Let’s see how the different types of object in Flux map to the CQRS pattern.

Actions

Actions are exactly the same as Domain Events. They should represent events that have happened in the past, and will cause updates to Query Models in the system.

Dispatcher

The Dispatcher is the Domain Event Publisher. It is a centralized place where Actions are published to. It also allows Stores to subscribe to Actions that are published in the system.

Stores

Stores listen for Actions published through the dispatcher, and update themselves accordingly. In CQRS, they would be the Event Subscriber.

In addition to being the Event Subscribers, they also act as Query Processors. This is intentionally similar to our implementation of CartTotalStore. In some CQRS systems, however, the Event Subscriber and Query Processor may not be the same object.

ActionCreators

ActionCreators are the Command Handlers. In this case, though, submitting Commands just means calling methods on the ActionCreator. As opposed to having Commands exist as a separate object.

e.g. ShoppingCartActionCreators.addItem(…)

As you see, the canonical Flux architecture is only one way of implementing CQRS in a system. It also adds a lot of objects into a system, compared with a normal DDD approach. Is added bloat worth it?

[Douglas Gugino]

also looking for any commentary on 

hapijs/hapi: Server Framework for Node.js

[Peter Hageus]

I’ve been struggling a bit with this, using Redux and ’smart’ middleware.

For example having a middleware execute http requests. This really blurs the command/event-line. The action becomes both, first it’s the command requesting an http call, then it’s an event notifying the request is performed. 

Really enjoy everything Redux, but haven’t really nailed naming yet. Would be interesting to see how others have handled this.

/Peter

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

[Chris Sampson]

I do it in async action creators. And use thunk middleware to make it work

[Peter Hageus]

How do you name your actions?

/Peter

[Chris Sampson]

Yep, I read https://github.com/reactjs/redux/issues/384 and came to the conclusion i would use the 'imperative mood' style on naming, which is more aligned with the original Flux pattern. This makes it a bit different to the past tense named events we are used to in the ddd/cqrs world. Imperative mood actions are more like ‘CONNECTION_STATUS_CHANGE’ over ‘CONNECTION_STATUS_CHANGED’ and ‘RETRIEVE_ALL_SNAPS_FAIL’ over ‘RETRIEVE_ALL_SNAPS_FAILED’. Its kind of weird to start with but you get used to it. One of the main reasons for no past tense is for UI events like mouseup/mousedown - How would they work in the past?

[Peter Hageus]

Pretty much what I’ve arrived at as well, but it’s bit of a mixed bag… Byt maybe thats OK, this is UI logic after all.

/Peter

[Antony Koch]

In Redux, I view actions, action creators as state modification, i.e. the write side. I view the connect() method and container components as the event side - they respond to the state having been modified in their own way. They don't care how the state was modified, only that portions of it might be different.