<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Udi Dahan on Blog</title><link>https://blog.djvelimir.com/tags/udi-dahan/</link><description>Recent content in Udi Dahan on Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 26 Sep 2026 18:08:57 +0200</lastBuildDate><atom:link href="https://blog.djvelimir.com/tags/udi-dahan/index.xml" rel="self" type="application/rss+xml"/><item><title>CQRS pitfalls and patterns</title><link>https://blog.djvelimir.com/post/conferences/cqrs-pitfalls-and-patterns---udi-dahan---ndc-oslo-2023/</link><pubDate>Sat, 26 Sep 2026 18:08:57 +0200</pubDate><guid>https://blog.djvelimir.com/post/conferences/cqrs-pitfalls-and-patterns---udi-dahan---ndc-oslo-2023/</guid><description>&lt;p&gt;As more developers apply Command/Query Responsibility Segregation to their projects, many find that it INCREASES the complexity of their systems rather than decreasing it, often without any performance benefits either. Join Udi for a look at where you should, and more importantly SHOULDN&amp;rsquo;T be using CQRS in your projects.&lt;/p&gt;
&lt;p&gt;CQRS can be a powerful architectural approach when applied to the right problems, but it can also introduce additional models, infrastructure, and coordination that increase the complexity of a system.&lt;/p&gt;</description></item></channel></rss>