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.
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
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:
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.
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?
At my job we have what I'll call an approximation of one of these command based APIs, looks like a classic RPC API. We also have a set of internal user procedures that are basically those escape hatches you mentioned. They are the source of almost every odd and problematic behavior we encounter in our normal API.
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?
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.