Hello, since EventSourcing has been a really important stepping stone in my career and I’ve invested significant time to understand and implement it I want to throw in my 2 cents. First I should note that I may be biased, but in my head EventSourcing (ES) and Domain Driven Design (DDD) are linked, even though one may use ES without DDD or DDD without ES they only have substantial impact when together. Without DDD, ES can be easily replaced with CDC (Change Data Capture) having less effort and effectively the same benefits. As such when I mention ES, it is assumed DDD is present.
I’ve done some form of ES in 4 companies so far, of which I must say only 1 saw substantial benefits using it, the other 3 had almost no benefit and in some cases I would argue it slightly hurt them. The reason? The business did not care for ES (even though they hired engineers to implement it).
The longer I’ve been working with EventSourcing and CQRS the more it has been becoming clearer that it’s not primarily a software architecture per say (even though it certainly is one) but rather it’s a business strategy. To successfully implement it you need you need 3 things ordered by importance:
- A complex domain and Domain experts who understand it
- Business who sees ES as their competitive advantage
- A technical implementation
ES exists to deal with complex problems, it’s a slow and steady approach. Technically we present the benefits of ES as enforced audit-log, async communication, having a time-machine and the ability to recreate state. But in fact the main benefit is the ability to handle ever increasing complexity on a logarithmic curve. Dealing with domain complexity however is not an engineering problem, it’s a business problem. ES/DDD requires a change in the methodology of how software is build, and it must start from the top, the business has to become an active part in designing the software, and that is done though defining Events and how they affect the state of the application.
So getting back to the subject of Ash Events, I think it’s a cool addition to the Ash ecosystem, but overall I don’t find that it will help businesses who want to adopt an ES/DDD strategy. Ash is pretty opinionated on how software is build (through Resources and Actions) that’s a far cry from Events, Aggregates and Handlers. The “Ash way” does not push you towards the change in methodology for building ES software, rather it makes it easier to write declarative resource oriented software (which is amazing in it’s own right).
In contrast, let’s take a look on Commanded, an ES/CQRS framework, it is also very opinionated, however it “pushes” you toward thinking about Events and how they affect the state of your application as the primary concern. Now don’t get me wrong, Commanded as any framework has it’s drawbacks, there are many times I found it was getting in the way of what we designed as a business, but with even with it’s flaws the intent on focusing on the right thing was there.
So in my opinion the “Ash way” is very different than the “ES/DD way” and I would not recommend it for a business that has decided to do ES. Nonetheless I am sure people will make use of some of the features AshEvents will provide to applications doing the Ash way.
All that being said I love Ash and it’s declarative way of doing things. That’s exacly why I choose to do my startup in Ash, “ES/DDD” is only really worth it when a particular business needs it.
