Event Modeling
eventmodeling.org
eventmodeling.org
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.
In what way does it get tiresome? In the increasing amount of read models needed?
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
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 - basics for domain modelling, read/write repositories, aggregates/roots
https://node-ts.github.io/bus/ - event/command service bus, supports workflows/sagas, queue technology agnostic (runs over sqs, rabbitmq etc)
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.
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?
I believe presenting slightly more open commands for internal use is the right idea, but sliding all the way to an arbitrary entity edit API is a quick way to break state expectations.
Yes this could also be solved by having perfectly crafted constraints in the business logic and/or DB, but what's more manageable? Managing a few extra specific APIs, or having every expectation perfectly defensively coded?
Was this written by a programmer? It seems someone is living on fantasy theory island.
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...
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
- Revisiting workflows: BPMN is dead. Long live the Functional Programming!
- 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.
"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.