Milan Jovanovic Tech

I've been coding in .NET for years, but I never built an event-sourced system. Event sourcing has always intrigued me, though. The idea of capturing every change and having a complete history of your data - it's fascinating. So, I decided to dive in. Not as an expert but as a curious developer. When I first encountered event sourcing, it seemed complex. But stripped down, it's a surprisingly simple idea: store changes, not just the current state. Think of a bank account or wallet. Normally, we'd just save the balance. With event sourcing, we record every deposit and withdrawal. The balance is then calculated from these events. This shift from storing state to storing events is the essence of event sourcing. With events, you can now create projections to produce read models. You can do data analysis on the event streams to gain business nights. It's a very flexible approach. But event sourcing is also very complex. - Significant mindset shift and learning curve - Performance, snapshots, projections - Event schema evolution If you want to learn more about event sourcing, I wrote this introduction for .NET developers: https://lnkd.in/e3Gg85pK Did you ever use event sourcing in production? What was your experience? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/4ep1EEU

Here's how you can handle a 1-to-1 relationship with Dapper. Let's say the object we want to return from a SQL query contains a nested object. For example, a line item and its product. You'll need to tell Dapper how to map the SQL query into a LineItem and Product object. You can also provide a delegate to connect the two. Learn more about SQL-to-object mapping with Dapper here: https://lnkd.in/eruwS_RF

𝗥𝗲𝗳𝗶𝘁 - 𝗮 𝗴𝗮𝗺𝗲-𝗰𝗵𝗮𝗻𝗴𝗲𝗿 𝗔𝗣𝗜 𝗰𝗹𝗶𝗲𝗻𝘁 I've spent countless hours working with external APIs. It's a crucial part of modern software development, but let's be honest - it can be a real pain sometimes. We've all been there, wrestling with HttpClient, writing repetitive code, and hoping we didn't miss a parameter or header somewhere. That's why I want to introduce you to Refit, a library that will help you build faster. Imagine turning your API into a live interface - sounds too good to be true, right? But that's exactly what Refit does. It handles all the HTTP heavy lifting, letting you focus on what matters: your application logic. Here's everything you need to know about Refit: https://lnkd.in/e5tpFTJh Did you ever work with Refit in your applications? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/4ep1EEU

If your Identity Provider's access token doesn't perfectly align with your application's internal authorization needs, you can use Claims Transformation. Claims transformation allows you to modify the claims before the application uses them for authorization. You can use Claims Transformation to fill in the missing claims from your database or some other source. Here's why this is helpful: https://lnkd.in/e26wccmW

Why do we need distributed locking? A practical example. 👇 Imagine you're at a busy café where everyone wants the last piece of cake. How do you decide who gets it without causing a riot? This is essentially what distributed locking does in the world of software. You've got multiple servers, each wanting to update the same piece of data. Without rules, it's a digital free-for-all. With a distributed lock: - Server A tries to grab the lock. If it succeeds, it processes the sale. - Server B tries next, but finds the lock taken. It waits or retries later, ensuring only one sale goes through. What if the server holding the lock crashes? That's where lease times come in. Locks expire, and someone else can claim it. Redlock is a popular distributed locking algorithm that uses Redis. But you can also do distributed locking with PostgreSQL advisory locks. Advisory locks are application-level locks that span a transaction's or connection's lifetime. If you want to learn more about pessimistic locking, I think you'll find this article interesting. Check it out here: https://lnkd.in/e7jfYPuy Have you ever heard of advisory locks in PostgreSQL? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/4cPKDmp

Imagine being able to find security risks when you build your code. You can do this with static code analysis. Here's an example build error warning me that my password hashing code is insecure. 👇 Static code analysis can help you write secure and consistent code. And you can also enforce this at build, even in CI pipelines. If you want to see how to set this up from scratch, check out this article: https://lnkd.in/erCDpB-N

Here's a crash course in distributed messaging with AWS. 📨 There are two services that you should know: - SQS (Simple Queue Service) - SNS (Simple Notification Service) SQS is a fully managed message queueing service. SQS acts as a reliable middleman for asynchronous communication. Messages are stored in queues and consumed on demand. SQS offers two distinct queue types: - Standard queues - Ideal for high-throughput scenarios - FIFO queues - When maintaining message order is required SNS is a fully managed pub/sub messaging service. It allows publishers to send messages to multiple subscribers (topics) simultaneously. SNS seamlessly integrates with SQS. SNS handles the fan-out of messages using topics, and SQS queues ensure that each message is processed exclusively by a single consumer (service). So, how can you use these services from a .NET application? You could use the official AWS SDKs. However, you will need to write more code to receive and handle messages successfully. So, I want to suggest a different approach. You can let MassTransit do the heavy lifting so you can focus on delivering business value to your customers. Here's how: https://lnkd.in/esHWfws5 Did you have a chance to use SQS and SNS? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/4cPKDmp

Are you accidentally crippling your EF Core queries? Before you start bashing on EF Core, this is an SQL problem, not an EF problem. But it can be problematic to find and fix with EF Core. Understand the Cartesian Explosion problem and how it occurs in your queries. I'll also give you a practical solution using EF Core's query-splitting feature. Watch the full video here: https://lnkd.in/eWn3xttu

Why do we use Domain Events? A domain event is something that happened in the domain, and other parts of the domain should be aware of it. I use domain events to notify other parts of my domain that something has happened. You can use domain events to build a loosely coupled system. Here's how: https://lnkd.in/ewA7miCr

What makes Vertical Slice Architecture an interesting approach? I'll skip the obvious parts you've probably heard elsewhere: - Improved cohesion - Easier navigation through the code - High coupling for a single use case - Low coupling between unrelated use cases But here's a not-so-obvious benefit of vertical slice architecture. - You can define the technical implementation details I may have one slice with complicated business rules, so I'll use Clean Architecture and a rich domain model. On the other hand, I might have a simple vertical slice, in which case a transaction script would be sufficient. I shared my simple approach to structuring vertical slices in a recent article. You can read it here: https://lnkd.in/etnHZGat What do you think about vertical slice architecture? --- Do you want to simplify your development process? Grab my free Clean Architecture template here: https://bit.ly/4cPKDmp