Hacker News Reader

Comment by oblique63 | Hacker News Reader

Maybe I'm not getting something, but all this Flux stuff reminds me a lot of DDD+CQRS (domain driven design w/ command query response segregation), to the point where it seems like it's the same concepts repackaged with different terminology.

This post in particular seems to be advocating the concept of having a single 'aggregate root' as opposed to independently loaded 'entities', and Flux sounds like it just advocates the use of an 'event bus' to send separate 'read'/'write' 'commands' to 'domain objects'... the main difference of course being that all this recently has been specifically with the browser in mind. Is that a reasonable assessment?

View on HN

Totally reasonable.

Amongst people that I associate with that build complex web apps, there's been an ongoing debate on whether a centralized event dispatch (what Flux advocates) is preferable to decentralized event emitting components (what Backbone and web components advocate).

For most of my career, I've been a fan of decentralized event emitting components. However, with Om's persistent data structures and functional render loop, having all of your data in a single place is suddenly a lot more palatable. From there, I think the event bus approach flows naturally.

Or at least, that's what I'm thinking now :) I still haven't written something with complex enough tests and other external dependencies to have gotten bit by this yet.

Yeah, I think it's basically the same concepts but repackaged for web developers. You can tell from the names - "React", "Om" and "Flux" sound like the kind of things web developers might use, and "Domain-Driven Design" and "Command/Query Responsibility Segregation" sound like things that enterprise developers might use. Both sets of names are a way of marketing similar concepts to different audiences.

I think many haven't heard of or know the DDD+CQRS terminology.

I even suspect if Peter Hunt mentioned how they are doing DDD+CQRS for building applications, it might have been met with ridicule from audience.

It is kind of interesting, the field of software engineering is not that old, but there already probably multiple cycles of the same concept being rediscovered over and over again.

Another rather cliche one is callback based concurrency. There was a wave of "oh look at this new thing we discovered, you don't block and instead provide a function to be called later". And many older folks probably looked at each other and said "Wait, what year is it?"

+1, I wonder if all reasonable immutable architectures share the same design foundations. Another example is datomic which if you squint only a little bit, is basically the same thing as CQRS/ES in shrink wrap

I think there's an important difference between CQRS/ES and Datomic, namely that Datomic is actually "just" a persistent data structure (in both CS senses of the word).

In CQRS/ES you don't usually want to store the state as such, you just store all the logical events which lead to a certain state. While the Datomic approach is certainly valuable for certain scenarios if you want to query historical data, it's less so if you want to know why something looks the way it currently does (in terms of the domain).

(At least that's my understanding of Datomic, I may be mistaken.)

Reply on news.ycombinator.com