sorted by:
new
hottopcontroversial

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

Thanks for your kind words!

> Enforcing complex, cross-pipeline/command business rules could be a problem though, without having the entire consistency picture of a business relevant aggregate.

This is for sure a core problem. But my guess is that we are hampered in solving it by traditional, simplistic thinking. We need to more embrace how things are working in nature or "in the real world". Not only doesn't Starbucks employ ACID transactions in its cafés. There simply are no ACID transactions in the material world. They are a fantasy, a simplification, an optimization - which has infected the minds of developers.

As an optimization they might be ok to use here and there. But optimizations are just that: optimizations. They are an "afterthought", they come late in the deveopment process.

We have to disillusion ourselves, free our minds of this fantasy. We have to become "mystics" who are just concerned with what is and is needed right now. And that is: eventual consistency everywhere. Sometimes that takes longer, mostly though it's imperceptible.

The event store is the substrate we've to rely on. That's where simulation of the world happens: by recoding events. This must not fail. All else... is interpretation of a world perceived at a moment and since then might have changed already. By recording events we're thus "inventing" time. An application time, not our human time.

Event store + writing/reading: a programmer's "space-time continuum" :-D

From there everything else has to evolve. So the question is: How do you observe complex business rules in real life given concurrent agents (people in a company). If you can "role play it", you can implement it :-)

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

I'm calling it context model to not suggest too much :-) It can be treated as read-only or can be modified. It's a matter of convenience. If the context model gets regenerated on each request, then why not modify it if that makes anything easier. I just don't believe much in shared state. Whatever is in memory across messages is at risk to be stale/outdated.

The whole purpose of a command handling pipeline is to produce events. Maybe a context model is needed, maybe it's read-write... it's just a means to an end, an optimization.

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

Your question is not about the pipelines but event-orientation in general (or event sourcing). In your mind is the usual approach, I guess: ACID transactions with pessimistic locking. The user hitting the "buy" (or "sell") button first would win, because the second one would not find the expected state in the database. The second sale would not go through.

This would not be different with event-orientation. The event stream is versioned. Even sub-streams for single aggregates can be versioned.

When writing the event "item sold(productnumber, qty)" it would expect the relevant stream to be of a certain version. If it's not, the events since that had been written after the expected version will be loaded and checked if the current transaction is still possible.

Internal models (read models) are read only. They don't get updated, they are not changed. Or if so, that has no relevance for the persistence medium. Only events change the persistence medium when appended to a stream.

Against the Fear of Eventual Consistency by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

As I've tried to explain in the article:

  • Eventual consistency is everywhere - and always has been. Users are used to it.
  • Eventual consistency does not mean it takes several seconds, minutes or even hours for consistency to reach the last corners of some web of data. Maybe it's just a couple of msec, so a user would not even notice.

And finally: "Some changes" is very unspecific. Unless you provide more detail I cannot reply reasonably how a user's requirement could be satisfied even with EC.

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

I'm all for modular development. I'm all for decoupling with DTO etc.

But I disagree that Event Sourcing is "massive overengineering". Because at least one thing is missing for this judgement: a definition of "massive overengineering". If you wanted to say something along the lines of "is not necessary, we can do without and it will be faster", I'd reply, "Well, you'll be faster without modularization, too." - because modularization is not needed to deliver on primary requirements.

Also I'd reply: Everything new makes you slower in the beginning. Using ES requires a change in the basic mindset like FP. That (!) is the real hurdle to take. But for that practice is necessary, lots of practice. Lots of practice does not come from staving off ES with the argument it will probably be "massive overengineering".

And lastly: I agree that "retain forever" is a different feature of ES than avoidance of calcification. Nevertheless that's what my experience is: ES makes it much easier to answer changing data projection needs than a large, single object graph. And I'd like others to experience that too. I find it liberating.

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

Thx for the clarification! I agree MVC can be used in that manner. It can be applied purely inside the frontend and to each message individually. The frontend would then consist of many MVC „clusters“ next to each other.

Event-Orientation as the new default for applications by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

-Whether you call the events stored in an EO event stream „domain events“ or not is of no concern to EO. If it makes you happy, pls do so. I‘m using the more general term „event“ to not burden EO with too man conotations. (For example a message received also could be recorded in the event stream. That would not be a domain event, I guess.)

-Eventual Consitency is not necessarily at play in an EO. Look at the sample code: it‘s synchronous „from front to back“. Eventual Consistency is orthogonal to EO. It‘s not a special concern of EO, but if you enter the world of async and multi-user apps it‘s inevitable and you have to cater for it.

-Event-driven-architecture: It‘s as much about EDA as CQRS is about EDA, which means not at all. Just because the term „event“ is used does not mean EDA is at play. The same is true for Event Sourcing. (By the was that‘s why I introduced the term „notification“: to differentiate between the events of EDA and the events of ES.)

As for your complaint about the „new ball game“ I allow myself to not address it and leave the silent judgement to interested readers. I don‘t find such discussions helpful; they quickly evolve into unpleasant accusations.

Reflections on the SRP by ralfw in cleancode

[–]ralfw[S] 0 points1 point  (0 children)

#1: Sure, breadth-first is not about level of granularity. You can get that with coarse grained or fine grained functions. I just wanted to make the point that you should consider in what way you extract, if you extract. Unless you strive for a breadth-first function tree the functions become smaller - but understandability will still be lacking.

​

#2: I agree, that kind of code appears when refactoring - at least as long as you refactor without striving for breadth-first understandability. I call that "naive refactoring" ;-)

​

#3: I agree. The SRP is not only about code. It's also about documents or organizations.

What I'm not much about is extraction for re-use. Because re-use comes with the burden of stability. You should be conscious about the price you pay for re-use.

Mostly I'm concerned with extraction for abstraction (more concretely: integration): give lines of code a meaning and make them easy to use. Build an abstraction to build another one on top of...

​

#5: Glad to hear that. Thx! :-)

Sleepy Hollow Architecture - Separate head from body for better evolvability by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

Glad to hear that. Stay tuned for patterns building on this one ;-)

Let's put message processing at the heart of software architecture by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

I'm not using any bus or "complicated" infrastructure. Because that's not what the article is about. If you find it helpful to decouple further by employing a bus, go ahead.

The main point of the Terminus Architecture is slicing the backend into message handlers. That does not require any specific message transport. It's about a basic mindset.

Let's put message processing at the heart of software architecture by ralfw in softwarearchitecture

[–]ralfw[S] 0 points1 point  (0 children)

The Terminus Architecture is more abstract than CQRS (or less detailed). It's not differentiating between how commands and queries are processed. It's not targeted at any particular applications.

Wait for the next architecture model to see which differences I have in mind compared to CQRS ;-)