I know you're being sarcastic, and I agree that marketingspeak is, as always, annoying.
But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months. That's when they use them at all; most places just make shit up, write it into the software, and then experience a lot of pain when it is slowly discovered that the model expressed in the code doesn't really match the domain.
Traditional processes for understanding the domain also tend to focus on nouns. That's understandable, as a lot of what we build (UIs, objects, API results, identifiers, database tables) are about nouns. But starting there can be hard, especially for novice users; they use an implicit domain model and domain language, but they have rarely thought about it, so prying it out of them can be half anthropology, half philosophy.
But events are something people understand better, as everybody knows how to tell stories. And over the last decade we've seen the rise in event-driven approaches to system design. Focusing on events can of course solve a lot of problems in distributed systems. But things like React also show how thinking about events and data flows help even at very small scales.
So I look forward to trying this out next time I have a new complex business domain to model. It looks faster, easier, and more fun. I'd then probably combine it with something like Patton's Story Mapping to figure out what needs to get built:
http://www.jpattonassociates.com/the-new-backlog/
But I do think this is revolutionary. The typical processes people use for understanding a novel business domain take weeks to months. That's when they use them at all; most places just make shit up, write it into the software, and then experience a lot of pain when it is slowly discovered that the model expressed in the code doesn't really match the domain.
Traditional processes for understanding the domain also tend to focus on nouns. That's understandable, as a lot of what we build (UIs, objects, API results, identifiers, database tables) are about nouns. But starting there can be hard, especially for novice users; they use an implicit domain model and domain language, but they have rarely thought about it, so prying it out of them can be half anthropology, half philosophy.
But events are something people understand better, as everybody knows how to tell stories. And over the last decade we've seen the rise in event-driven approaches to system design. Focusing on events can of course solve a lot of problems in distributed systems. But things like React also show how thinking about events and data flows help even at very small scales.
So I look forward to trying this out next time I have a new complex business domain to model. It looks faster, easier, and more fun. I'd then probably combine it with something like Patton's Story Mapping to figure out what needs to get built:
http://www.jpattonassociates.com/the-new-backlog/