borar

A new blog article where I go against the de facto normal: "Event sourcing is record storing" #eventsourcing systema10.org/posts/event-...

While I understand the good intentions behind such reocurring statements, I am less careful and "politically" balanced: #fsharp is absolutely inherently better. The "needs" are irrelevant, objective properties are what matters in engineering. Just like precise power tools vs manual mediaval tools.

My 5c about this, as always somewhat heretical. "Bounded context" is vague and not really interesting/useful. Vertical slice architecture is not an architecture, but a principle *within* an architecture. In particular, in the Onion architecture (my default). #DDD 🔽

Every vertical component has its own data access interfaces (remember, Onion), URL handlers, data access implementation, tests, etc. Vert. components can also share types and functions from "common modules" which are at the "base" of the vert. components. For example the common User type. 🔽

My 5c about this, as always somewhat heretical. "Bounded context" is vague and not really interesting/useful. Vertical slice architecture is not an architecture, but a principle *within* an architecture. In particular, in the Onion architecture (my default). #DDD 🔽

A vertical slice, which I usually call a vertical component, is a cake piece going through all layers of the Onion. It is a mini application on its own, in a way, focusing on a set of related use-cases. Not too fine-grained, for example all use-cases of user management is one vert. component. 🔽

Streams per entity are fundamentally in conflict with the basic essence of #eventsourcing. The essence being that we can compute *anything* by folding all records. Counter-example: find all customers in a system where each customer has a dedicated journal/stream by customer ID.

By continuing this reasoning, "closing the books" is also fundamentally in conflict with the essence of #eventsourcing. If we "close" a journal with some summary datum D, but need to compute D' one second later or one year later due to nee requirements, the closing was pointless. 🔽

Some heated discussions below. I am working with something similar right now. In 2013 I made an in-house message broker at work with my own algorithm for historical + real time event stream generation. We are still using it now. 🔽

Either implement distributed transactions (actually communication between Windows DT managers) "manually" or provide transactional event logging in some other way. We went with the latter, introducing a new client library with, you guessed it, the outbox mechanism. It works well. End of story.

Some heated discussions below. I am working with something similar right now. In 2013 I made an in-house message broker at work with my own algorithm for historical + real time event stream generation. We are still using it now. 🔽

A killer feature was not only "temporal subscriptions" with a stream transparently transitioning from replaying historic data to real-time events, all per subscriber, but also transactional event logging. The broker could participate in the distributed transaction with a source application! 🔽

Another suspicious property of aggregates is that they (I think) collapse the application and model layers of the application. If an aggregate is essentially the scope/boundary of everything which is allowed to happen (consistently) within a use-case, then it means that the model layer 🔽

Next potential problem of aggregates: they discourage proper modeling. Aggregate thinking pushes the programmer to lump together numerous entities (abstractly speaking) just for the sake of "consistency". This means an application often gets a single big en "universal" representation of 🔽

Another suspicious property of aggregates is that they (I think) collapse the application and model layers of the application. If an aggregate is essentially the scope/boundary of everything which is allowed to happen (consistently) within a use-case, then it means that the model layer 🔽

Consequently, if each aggregate is essentially a use-case-as-class/object, it is easy to make the mistake of also doing the I/O inside of that object. Which collapses the architecture even further. Commands and domain events are a manifestation of that.

Another suspicious property of aggregates is that they (I think) collapse the application and model layers of the application. If an aggregate is essentially the scope/boundary of everything which is allowed to happen (consistently) within a use-case, then it means that the model layer 🔽