Why Event-Based Systems? | Enterprise Node.js + TypeScript

Last updated Dec 27th, 2019
There are so many reasons why event-based systems are the standard for large-scale enterprise applications like GitHub, Facebook, Google, etc. In this article, I list a few reasons why I believe in 'em.

There are several ways to design systems. When I first starting building applications, I would start out with the database. Eventually, I realized that the view dictates the data, so I moved to starting out with the UI. Then I realized that I was failing to represent a lot of important business rules, so I began to search for something else.

Eventually I found Domain-Driven Design and starting building applications by first understanding the domain, then working upwards from the domain layer.

I then realized the utility of domain events and the fact that you can illustrate an entire business's operations on a timeline with domain events.

Designing systems from domain events instead of columns in a database, endpoints on an API, or components in a view, has so many benefits.

Here are just a few.


Thinking in terms of domain events is the closest we can get to expressing what happens in the real world. Features can be communicated by non-technical folk as a series of domain events.

UserRegistered -> EmailVerificationSent -> EmailVerified

Auditing & Reasoning

When we represent a system using events, we can reason about the way that the system changed over time since the current state is computed by applying all of the domain events that ever occurred. In some domains, this is mandatory for audits.


Software can be a very creatively unbounded process. Find and count all the views (read models) that present data and commands (write models) that change the system and cause domain events, then measure their complexity.

The views and commands that a system needs in order to be complete are called "Use Cases" and adhere to the Command-Query Segregation design principle. Read "Better Software Design with Application Layer Use Cases | Enterprise Node.js + TypeScript" to learn more about how to design with use cases.


Sometimes, in large applications- a single transaction might need to pass through or notify several other systems. In high-traffic scenarios, instead of blocking an async call, we introduce "Eventual Consistency" as a way to enable systems to "catch up" eventually.


Business rules are often missed in CRUD-first design. In order to avoid unmaintainable if and else statements and anemic domain models, think in terms of events, the commands they sometimes invoke as side effects, and the preconditions that govern how and when they can be invoked.


Event-based architecture seems to be the common place to go when the problem we're solving with software gets really large.

Unfortunately, there's a bit of a learning curve.

If you're interested in learning event-based systems, here's what I think the general learning path looks like:

  • Get really good at one programming language to the point where it feels like breathing for you.
  • Understand what an anemic domain model looks like and if you have one.
  • Learn about Event Storming and how it can help you plan a project using events.
  • Learn Domain-Driven Design concepts like entities, value objects, aggregates, and domain events.
  • Learn about CQRS and why you would want to use it in your DDD project.
  • Learn about Event-Sourcing
  • Build an application using DDD, CQRS, and Event-Sourcing.


Liked this? Sing it loud and proud 👨‍🎤.

Stay in touch!

About the author

Khalil Stemmler,
Software Essentialist ⚡

I'm Khalil. I turn code-first developers into confident crafters without having to buy, read & digest hundreds of complex programming books. Using Software Essentialism, my philosophy of software design, I coach developers through boredom, impostor syndrome, and a lack of direction to master software design and architecture. Mastery though, is not the end goal. It is merely a step towards your Inward Pull.

View more in Enterprise Node + TypeScript

You may also enjoy...

A few more related articles

Clean Node.js Architecture | Enterprise Node.js + TypeScript
In this article, we'll look at the various different versions of the "clean architecture", simplify it, and understand how we can ...
Knowing When CRUD & MVC Isn't Enough | Enterprise Node.js + TypeScript
MVC the granddaddy of application architectures. In this article, we explore common MVC patterns, the responsibilities of the "M"-...
Use DTOs to Enforce a Layer of Indirection | Node.js w/ TypeScript
DTOs help you create a more stable RESTful API; they protect your API clients from changes made on the server.
Functional Error Handling with Express.js and DDD | Enterprise Node.js + TypeScript
How to expressively represent (database, validation and unexpected) errors as domain concepts using functional programming concept...