Event sourcing (and CQRS in general) is often compared (as comments here are doing) to "simple" CRUD and why add the complexity.
The difference is that event sourcing, aggregates and CQRS force you to actually identify the entities and the external and internal events that cause them to change.
It forces you to do the analysis that you should do anyway, but is often lost or forgotten when it devolves to "simple" CRUD. You end up adding change logging, histories, materialized view updating etc etc, all of which come "for free" if you do the work to establish what you're trying to build.
WALs are not the same as a business level entity/event stream, WALs are event streams for the database, not the business logic you're using the database for.
Yes, it is more complex, but, in combination with techniques like domain driven design and creating ubiquitous languages, your business logic will end up actually being simpler and closer to reality.
The difference is that event sourcing, aggregates and CQRS force you to actually identify the entities and the external and internal events that cause them to change.
It forces you to do the analysis that you should do anyway, but is often lost or forgotten when it devolves to "simple" CRUD. You end up adding change logging, histories, materialized view updating etc etc, all of which come "for free" if you do the work to establish what you're trying to build.
WALs are not the same as a business level entity/event stream, WALs are event streams for the database, not the business logic you're using the database for.
Yes, it is more complex, but, in combination with techniques like domain driven design and creating ubiquitous languages, your business logic will end up actually being simpler and closer to reality.