Event sourcing is a pattern (antipatern?) that appears useful because it solves an interpersonal problem. It is the kind of thing that middle management salivates over because it appears to decentralize control, which to such a manager sounds like "gives me more control of my own sphere". Every team creates their own event schemas and subscribes to other teams' events and we all live happily ever after. Never again will we have to wait on some other team to spin up an API for us! It promises an engineering solution to engineering itself.

I could write and write and write about it, but this rather infamous blog post is so good I'll just link it. https://chriskiehl.com/article/event-sourcing-is-hard

There hasn't been an improvement on software architecture state of the art since SmallTalk and Relational Databases. Everything else is either a rehash or a rebuttal that proves short lived and ends in a rehash.

I get the relational bit. But can you expand on the Smalltalk one?

Smalltalk got a lot right very early on that got adopted in bits by everyone eventually. The idea of a fully interactive IDE, designing systems as distributed objects that exchange messages, and so on.

Unfortunately parceling it out and fudging it killed a great concept and we got stuck with corporate driven "OOP" that lives on in Java, Kubernetes, etc.

It's a wonder the people at PARC divined so much of great conceptual designs and other companies got to profit from bungled versions thereof.

There were several great ideas at parc, indeed. I think the most powerful one goes unnoticed by most, which is how it was managed by Bob Taylor.

Smalltalk is not perfect, it had some good ideas, but also some bad ones (in the sense of not being practical in most contexts) like the "image" mixing of code and data.

Far from perfect indeed. Yet it encapsulated so much of software architecture that is still relied upon and hasn't been advanced significantly since.

> There hasn't been an improvement on software architecture state of the art since SmallTalk and Relational Databases. Everything else is either a rehash or a rebuttal that proves short lived and ends in a rehash.

I explained the same thing to my mgr who is non-technical but is exposed to the relentless flow of tech trends and hype.

I explained:

1-There are 2 developments that have been complete successes:

Relational

The internet

2-Every other trend has some value for some problems but is not a silver bullet and typically does not live up to the enormous hype the industry applies to every new thing. Our job is to pick and choose which tools+methods work for the problems we are trying to solve.