Discover and read the best of Twitter Threads about #EventSourcing
Most recents (11)
My blog post "Event Driven Architecture — 5 Pitfalls to Avoid" just crossed 45K views!
some important comments i've received in 🧵1/3
link: medium.com/wix-engineerin…
@WixEng
some important comments i've received in 🧵1/3
link: medium.com/wix-engineerin…
@WixEng
1. What about using #OutboxPattern?
While a good pattern to use, for @WixEng we decided that #WixGreyhound Resilient producer provides high enough evnt publishing guarantees that we can avoid the extra DB pressure and complexity of Outbox. We may go with #Debezium as well 2/3
While a good pattern to use, for @WixEng we decided that #WixGreyhound Resilient producer provides high enough evnt publishing guarantees that we can avoid the extra DB pressure and complexity of Outbox. We may go with #Debezium as well 2/3
2. Event-driven architecture #EDA and #EventSourcing are unrelated. one talks about services communication while the other on persistent layer
Yep, you're right! I should add a disclaimer here... but event-sourcing will affect how you communicate between services... 3/3
Yep, you're right! I should add a disclaimer here... but event-sourcing will affect how you communicate between services... 3/3
The missing Ruby on Rails architecture
🧵let me explain the 10 rules here
🧵let me explain the 10 rules here
1. App layer vs domain layer
Assume that controllers and service objects are app layer (a bit simplification here, but bear with me).
Service objects can never call each other. They are the application facade.
Assume that controllers and service objects are app layer (a bit simplification here, but bear with me).
Service objects can never call each other. They are the application facade.
2. App layer modularisation is based on what "apps" you have
Usually you have some public facing app, admin panel, mobile API, some integrations.
Those are good candidates for "modules" at the app layer. Don't confuse it with domain layer.
Usually you have some public facing app, admin panel, mobile API, some integrations.
Those are good candidates for "modules" at the app layer. Don't confuse it with domain layer.
After getting the first version of #Java samples of #EventSourcing, I asked the community for feedback for my PR
github.com/oskardudycz/Ev…
I wanted to get harsh but fair feedback to make it idiomatic and, in general, better. I got what I ask for, let me share what I learned 👇😅 1/
github.com/oskardudycz/Ev…
I wanted to get harsh but fair feedback to make it idiomatic and, in general, better. I got what I ask for, let me share what I learned 👇😅 1/
Java Optional should be used only as a result, to reduce the confusion around the `void` type. It should not be used as a method input parameter or field. This makes sense, as Java generics are more compile-time templates and are zipped. See more in: nipafx.dev/design-java-op… /2
I already used sealed interfaces to have a nice pattern matching while rebuilding the state from events. Yet it appeared that they allow full "union types" experience! After that, I went further and created 👇It enables concise and precise modelling /3
My #fsadvent post is up:
Functional Event Sourcing Decider
thinkbeforecoding.com/post/2021/12/1…
At last, a full length blog post about functional #eventsourcing
#fsharp
Functional Event Sourcing Decider
thinkbeforecoding.com/post/2021/12/1…
At last, a full length blog post about functional #eventsourcing
#fsharp
@sergey_tihon here it is.
This is a long post based on my upcoming book about Functional Event Sourcing. Not ETA yet, but I thought I still needed to publish something at some point. There is of course far more content in the book 😁
If you’d like to know why you may not need snapshots and learn modelling patterns to do #EventSourcing efficiently, read my latest article on @eventstore blog 👇
It may sound blatant, but I think that there are not many resources like that on this topic 1/
eventstore.com/blog/keep-your…
It may sound blatant, but I think that there are not many resources like that on this topic 1/
eventstore.com/blog/keep-your…
It’s a looking article, much longer than the length of the streams you should keep in the event store 🙂 I tried to keep it shorter or split it, but my main goal was to provide a thorough, nuanced and complete explanation. So grab a glass of preferred drink and have a read 2/
This is the third part and (hopefully) the last one of the triad about temporal modelling patterns. I started with a general introduction, explaining closing the books as to why you should reconsider your decision about snapshots. 3/
eventstore.com/blog/snapshots…
eventstore.com/blog/snapshots…
Thread:
I've seen many implementations of #eventsourcing that use a message broker to publish events to the read models. I've used that pattern and contributed to ES "frameworks" that implement that pattern.
I think It is a bad idea. I'll explain why:
I've seen many implementations of #eventsourcing that use a message broker to publish events to the read models. I've used that pattern and contributed to ES "frameworks" that implement that pattern.
I think It is a bad idea. I'll explain why:
1) Writing to the event store AND publishing events to a broker needs to be atomic.
In most cases a distributed transaction using two phase commits is not an option.
We need to create some mechanism to deal with faulty connections between publisher and broker:
In most cases a distributed transaction using two phase commits is not an option.
We need to create some mechanism to deal with faulty connections between publisher and broker:
To reliably/atomically update the event store and publish events to the broker, we can use the Transactional Outbox Pattern:
microservices.io/patterns/data/…
microservices.io/patterns/data/…
A thread about what we have learned after ~1y of #EventSourcing.
Context:
- Domains: Billing, Accounting, Cashflow.
- Volume: 750k events / day
- Services count: 10
- Private cloud/infra
- Stack: #fsharp / postgres / rabbitmq
Caution:
Very opinionated, we're learning every day.
Context:
- Domains: Billing, Accounting, Cashflow.
- Volume: 750k events / day
- Services count: 10
- Private cloud/infra
- Stack: #fsharp / postgres / rabbitmq
Caution:
Very opinionated, we're learning every day.
Without modeling, never create a new stream or add a new event. Your self-confidence could be your enemy.
Event names and event models must be double checked with the business and the team.
Event names and event models must be double checked with the business and the team.
Events should always be business events.
Avoid using them or their fields as a logger (You have elastic for that).
"AlreadyReceived" for example, should not be an event but maybe a command error.
Avoid using them or their fields as a logger (You have elastic for that).
"AlreadyReceived" for example, should not be an event but maybe a command error.
TDD is about design. So with @eventmodeling
it goes out the window. What you have is unit tests to help give you regression tests. But even then, you are doing OCP more than recent years allowed. So plow through the happy path ASAP. Use THAT as the backbone to your system.
it goes out the window. What you have is unit tests to help give you regression tests. But even then, you are doing OCP more than recent years allowed. So plow through the happy path ASAP. Use THAT as the backbone to your system.
More on this at tomorrow's meetup. This is truly agile. I never thought I would ever think to discourage #TDD. But here I am saying exactly that after practising it for 20 years.
So plow through the happy path as fast as possible. Add unit tests later to make sure you covered all the nuances of the data transformations. The regression tests aren't as necessary if you are doing #eventsourcing as you have a bread-crumb trail of how you got into any issues.
@HaripraghashS @HaripraghashS 2 short questions without 2 short answers 😅But let's try! Projections for me when I started my journey with #EventSourcing was the hardest thing to understand. I thought: ok, I can rebuild the aggregate state by replaying events one by getting them by id 1/
@HaripraghashS Having that I'll have the state of the single aggregate. Wait a minute! If I won't to do that for the aggregate list then I'd need to get all events for those aggregates and reply it one by one? Nah that's can't be! For that we have we have projections. As you for sure know /2
@HaripraghashS What are projections? It's just representation and interpretation of the set of event. What's more when we're replying events to get aggregate state - that's also projection. It's easy to forget about that because it's default case. We're just interpreting events to get state /3
Bir yazılım geliştiricinin bilmesi gerekenlerle ilgili 15 maddelik flood geliyor.. Mümkün olduğunca fazla keywordü bir araya toplamaya çalıştım.
Hadi Başlıyoruz!
#Developer #Software #Java #code #kod #yazılım #development #computer #bilgisayar #tool #PC #IT #web #tech #data
Hadi Başlıyoruz!
#Developer #Software #Java #code #kod #yazılım #development #computer #bilgisayar #tool #PC #IT #web #tech #data
1-Temel veri yapıları (linkedList, map, tree vb) ve temel algoritmalar (sıralama, arama vb)
Sıfırdan kodlama ihtiyacınız büyük ihtimalle hiç olmayacak. Ancak ihtiyaç anında doğru yerde doğrusunu seçebilmek için o veri yapısının veya algoritmanın nasıl çalıştığını bilmeniz şart
Sıfırdan kodlama ihtiyacınız büyük ihtimalle hiç olmayacak. Ancak ihtiyaç anında doğru yerde doğrusunu seçebilmek için o veri yapısının veya algoritmanın nasıl çalıştığını bilmeniz şart
I feel very sad about this, but I am compelled to comment. This article does such a great disservice to #DDDesign #CQRS and #EventSourcing that if my platform/toolkit/framework where cited in it, I'd demand removal:
The software industry is continuously exposed to such poor literature and guidance. The term "domain model" should not even be used here, nor "domain event." Even so, the whole article is flawed. Please don't follow this advice.
Unfortunately this article argues "accidental complexity" as a reason to change the "domain model" and then goes about introducing heaps of unnecessary complexity. This appears to be an effort in showcasing a framework rather than simplifying the solution.
