Oskar Dudycz’s Post

How do we catch breaking changes in our contracts? Better quickly! Jokes aside, it's better to have the right tools to do it. And do it before we introduce breaking changes, not after we do it. I just merged the examples showing 3 tools that you can use in .NET project to benefit from them: 1. Verify for Snapshot Testing. 2. PublicApiGenerator to snapshot the public API. Combining it with Verify allows you to detect breaking changes on your CLR API. 3. NuGet Package Validation to compare the new NuGet version with the published one. See all examples in: https://lnkd.in/dPGufHGH P.S. Yes, you can clearly see by the number of activity that I'm doing a final touches before the Domain-Driven Design Europe workshop 😅

Final countdown! On Monday, the signings will close for my Production-Grade Event Sourcing workshop on Domain-Driven Design Europe. There are still some places left. If you're thinking of going to production, validating your design, getting my brain and my experience, or just having some fun, feel invited! For those who join it, I'll also give you a half-year free trial for #ArchitectureWeekly, giving you even more material to learn after the workshop! Please ask if you have any questions, happy to clear all of that out.

Are you looking for a no-BS introduction to observability in your .NET project? Check the article by João Antunes https://lnkd.in/dBbZmmAR Together with the accompanying code, it's probably the best introduction I found. It's thorough, actionable and shows non-trivial cases. Of course, it won't take you from zero to hero, but at least from zero to "I'm in the good point to build proper observability". Plus, follow João and check other things in his blog. There are many creators generating stuff for clicks, but with João works, it's visible that it's a diary of the journey. And that's what I call good blogging 🙂

Some time ago, I wrote that I won't use .NET #Aspire for now, and now I checked it again. Result? It got better! Now I can finally use it! 😅 I faced some issues again, but non-blocking this time. It's clearly visible that the team is motivated and working hard to improve it. I was really impressed by the response time, discussion on Discord with David Fowler and quick turnaround for the issues I found. Much appreciated! Aspire still has rough edges, but now I see already that it can be useful for the local dev. For deployment? Possibly, but I need to learn more. It's not yet time to say for 100% that it'll be my default option for .NET projects, but I appreciate the pace at which it evolves. I'm planning to spend more time on it and maybe even contribute. Definitely not Nay anymore 🙂 If you're curious my current state of the art, check the PR https://lnkd.in/dU6c9kU6 It's not perfect, but it already uses multiple services with service discovery, Kafka, PostgreSQL with Marten. Stay tuned, I'll have more stuff there soon.

It’s been a while since the first edition of Papers We Love in #ArchitectureWeekly. In the first one, we tackled Sagas by Hector Garcia-Molina and Kenneth Salem. Next week (Thursday 23rd, 6PM CEST), we’ll tackle something less techy; we’ll go with socio-technical, and what better reference to do it than the famous article Mel Conway wrote when he introduced his law? You probably know already the quote: "Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations." Now, we’ll read the whole paper. It’s incredible that this became like a gravity law. It always works, for better or worse. You can find the article here: https://lnkd.in/d5gZ_cF4. Together with reading, we’ll have the chance to discuss our experience and past challenges facing this hard law. I count on you that you join and add your feedback, and we’ll have an intriguing discussion! Become a paid subscriber and join us live and get access to past webinars: https://lnkd.in/d_ZhQnAt I hope to see you there!

Everyone likes to talk about best practices. I went the other way around and gathered all the worst practices on how to build the worst Event Sourcing system. Was it easy? It was not, as building the worst Event Sourcing system, we cannot cheat and just go with Event Streaming rebranding the name. What to do next? Check the recording of my talk at #NDCLondon where I told the story of the project Franz: the worst Event Sourcing system. https://lnkd.in/dg3xK_8P Jokes aside. Event Sourcing is perceived as a complex pattern that’s challenging to learn. In fact, it's pretty simple, but the common misconception and the way it's taught may lead to such a conclusion. By going through the worst ideas, I wanted to show the essence of Event Sourcing. p.s. that was probably the hardest talk I gave so far from the presenting technique. The narrative has a few twists, so feedback is more than welcomed!

Would you like to use #EventSourcing in Node.js space but don’t know a mature tool to do it? I know how hard it’s to get started and I’d like to cut the ramp up phase for you with #Emmett.  Last weeks I’ve been busy preparing my workshops for Techorama and Domain-Driven Design Europe but from June I’d like to speed up the effort with Postgres storage, subscriptions and telemetry. If you’d like to be part of it and help deliver missing features for you - contact me. Getting financial support will help me to prioritise this Open Source effort and deliver features that can boost your project delivery. I’ll appreciate resharing to your friends that may be interested 🙂