
Event Modeling - eterps
https://eventmodeling.org/posts/what-is-event-modeling/
======
healsjnr1
I love that this focuses on event modeling as opposed to CQRS / Event Sourcing
specifically.

Those patterns are useful (CQRS and ES), and they imply a certain design, but
event modeling and domain driven design are what really tie systems together.

One thing I'm not sure I entirely agree with though is the flat cost of
change. We've been working on an event modeled system for about 4 years now.
It has grown in complexity and we've learnt a lot and we've invested a lot.

At this point we are probably approaching a flat cost, but initially our cost
increased quicker than a traditional project.

There are a lot of pitfalls and learnings about building a system this way.
Building read models gets very tiresome, and dealing with concurrency and
idempotency are still hard (you just have a better tools / language for
dealing with them).

Having that, once you break the back of this and build the internal skills, it
is a great way to work and I really believe the systems will scale much more
easily (both in performance and feature capacity). It's worth realising the
effort to get there is substantial tough.

~~~
eterps
> Building read models gets very tiresome

In what way does it get tiresome? In the increasing amount of read models
needed?

~~~
healsjnr1
That is one issue, as the number of services needing a model increases, you
end up repeating this.

It also becomes more complex as your domain grows and the complexity / number
of events increases.

Finally it can introduce a high degree of coupling, which ironically is
something event modeling hopes to decrease. In this case if you have 5 or 6
consumers all building their own read model, but relying on specific events,
the consumers are more deeply coupled into the services that emit these
events.

They now all need to be updated if something fundamental changes in the
systems supplying events.

I'm our case we used two techniques to mitigate this: \- defined 'public'
events with a clear api. These are the only events any external consumer
should consume. Yes, it introduces some versioning ave migration issues, but
also creates a clear and very helpful boundary. \- defined read model as it's
own domain and gave it a service. This is not always usable, but in many cases
the model clients need of the entire system is fairly standard. This way they
can integrate with a more typical query to pull the model rather than building
it from scratch

------
redact207
Event modeling and domain driven design go hand-in-hand, and learning both was
a huge turning point in my development career. It helps align software to the
business, and technical to non technical staff in a way where everyone speaks
the same ubiquitous language (when a user registers) more than other
approaches (rest - when I POST a user, crud - when I create a user).

It took me a few books and a couple of projects before the penny dropped, but
now everything else seems disorganised and difficult to keep a lid on
complexity as projects grow.

If your in Nodejs/typescript land and wanting to get started with DDD and
eventing like the article, there's:

[https://github.com/node-ts/ddd](https://github.com/node-ts/ddd) \- basics for
domain modelling, read/write repositories, aggregates/roots

[https://node-ts.github.io/bus/](https://node-ts.github.io/bus/) \-
event/command service bus, supports workflows/sagas, queue technology agnostic
(runs over sqs, rabbitmq etc)

------
gnud
See, this looks very logical, and a "command based UI" is great.

But the diagram is missing _all_ the complex steps, that makes this type of
system a lot of work to build and maintain. You need to be able to cancel. You
need to be able to extend bookings, or change the room type. Sometimes, this
will incur a fee, and sometimes not.

In my experience (not from hotel systems), the operators _will need_ a way to
actually edit the full state of the bookings. A registration form and a read-
only 'booking view' will not cut it.

I think it's a good idea to keep the "command-based UI" going for
external/end-users though.

~~~
supahdup4h
I think you are conflate not understanding context of how state needs to
change vs we need to arbitrarily change state ad-hoc.

The diagram isn't missing anything. It only describes the flows that it
contains. This how I build all systems. It works. Nothing you've mentioned
demonstrates a failure in this style of system design. I would suggest maybe
there is a gap in your understanding?

------
codr7
I feel like Rich Hickey, Clojure and Datomic deserve to be mentioned here;
given the amount of effort he's gone through to communicate these ideas and
provide neat tools to make them easier to implement.

------
koonsolo
> The biggest impact of using Event Modeling is the flat cost curve of the
> average feature cost. This is due to the fact that the effort of building
> each workflow step is not impacted by the development of other workflows.

Was this written by a programmer? It seems someone is living on fantasy theory
island.

~~~
ellistev
It’s true. I’ve seen this in action. Multiple workflow steps being built up
independently of the others and with a huge array of different
languages/frameworks.

------
AdieuToLogic
This paper/approach is reminiscent of "Enterprise Integration Patterns"[0] use
of messaging. As others have noted, this architectural approach can be quite
powerful and allow for system evolution.

Event Modelling, as described by the post, goes beyond EIP by taking a
component approach into the UI though. A good thing IMHO.

0 - [https://camel.apache.org/manual/latest/enterprise-
integratio...](https://camel.apache.org/manual/latest/enterprise-integration-
patterns.html)

------
newcrobuzon
Nice article and nice visualizations.

The problem I usually run into is the complexity - examples of event flows
almost always look super cool, but in real life scenarios, the complexity is
usually huge and complex flows are very hard to visualize in an organized
manner.

Whether you are talking about Event flows, BPMN or TOGAF - if your workflows
reflect all the real-life complexity (e.g. booking cancellation, editing,
extra charges etc. etc.) it will get almost impossible to visualize them
concisely.

Shameless plug:

I wrote few blog posts on the subject and also created a workflow tool to
address this problem:

\- Visualizing large workflows using D3, React and Clojurescript

[https://www.titanoboa.io/visualizing-
workflows.html](https://www.titanoboa.io/visualizing-workflows.html)

\- Revisiting workflows: BPMN is dead. Long live the Functional Programming!

[https://www.titanoboa.io/revisiting-
workflows.html](https://www.titanoboa.io/revisiting-workflows.html)

------
alipang
It's funny how server-side and client-side architecture moves almost entirely
hand-in-hand. Going by how we talk about things you'd think these'd be
entirely different.

\- The Model-view-controller architecture was moved to the server-side by ROR
and its descendants.

\- The javascript eventing model that was suitable for non-blocking UIs being
moved server-side via Node.js.

\- Now we're now also aligning around event/command-driven models for "state-
management" (Redux, event-sourcing/CQRS).

\- Event-streams like Rx.js being briefly hyped, but not gaining too much
adoption (?) both for GUIs and servers.

It's nice to see that general programming principles are still applicable
across domains.

------
whalesalad
Event-driven systems are great. They’re not for everything, and oftentimes
when you’re first introduced to, and start thinking in events, you might
notice a tendency to start seeing all problems as a nail with a big hammer in
your hand. That being said, it’s a fantastic approach to exercise and keep in
your toolbox for the situations where it can help.

------
mooreds
Thought provoking and it's be interesting to try out on a project. There were
some hand wavy sentences around legacy systems:

"With proper buy-in, the organization can agree to not alter the existing
system. Instead, dealing with bugs and adding new functionality is done on the
side as a side-car solution."

But I understand their point. Kinda like strangling the monolith--sometimes
the best way forward is to start over.

Has anyone actually done this and seen the flat cost curve? I worry that the
components will be entirely independent in theory, but not in practice.

------
GordonS
Anyone know what tool was using to generate these diagrams?

~~~
chrisvalleybay
I think they’re made with Miro (formerly Realtimeboard). Can’t recommend it
enough!!

~~~
loceng
Miro needs to target startup founders - it looks pretty close to if not
exactly the functionality I've been looking for for awhile now. Thanks for
pointing them out.

