Interview with Dino Esposito, the author of the book “Microsoft .NET: Architecting applications for the enterprise”

As I see things, CQRS is the most effective pattern today for building nearly any sort of applications. CQRS is about using neatly separated stacks for commands and queries. It’s like having two simpler domain models instead of just one that takes care of both aspects thus amplifying complexity. The query stack of a CQRS solution is extremely simple and usually consists only of a plain query layer on top of LINQ or ADO.NET. The command stack instead typically, but not necessarily, expresses the business logic in tasks and implements them through commands, events and their synchronization. Like icing on cake, event sourcing is about storing events and using events as the primary data source of the application. You have no relational model to persist; you just have events logged to form the entire history of the system and replay events to build and rebuild the state of entity objects on demand. When it comes to the actual implementation there are quite a few extra details to figure out but that’s just what you’ll find out in the class.   

Honestly, I don’t think there are significant downsides to using CQRS. CQRS is a pattern that suggests you have two distinct layers: one filled with the model and services necessary for reading, and one with the model and services for commands. What a model is—whether it is an object model, a library of functions, or a collection of data-transfer objects—ultimately is an implementation detail. With this definition in place, nearly any system can benefit from CQRS and coding it doesn’t require doing things in a different way than in the past. Neither does it mean learning new and scary things. So in summary CQRS in a way is a better and more scalable way of just doing CRUD. 

CQRS can be seen as an evolutionary step from Domain Driven Design or DDD for short. DDD originally pushed the idea of a whole, all-encompassing model capable of supporting all aspects and processes of a given domain. For over a decade, however, people struggled to build systems according to DDD guidelines. Some projects that embraced DDD eventually worked; other projects failed. Success stories can be told too, but many people still believe that DDD is hard to do even though it can possibly deliver significant benefits. The point, as I see things, is that, for many people, the perception that DDD brings benefits is much less concrete than the perception of the damage that might result from doing DDD and failing. In this context CQRS breaks things up. One all-encompassing model is often too complex and scary. What do you do in any application in the end? All you do is executing UI commands and query for data. Let’s then have two distinct layers for that. In fact, CQRS means Command and Query Responsibility Segregation. 

You are the author of many popular books on software engineering. Your latest book on software architecture just hit bookshelves. What message do you want to communicate to your readers? 

As developers, we know very well Murphy’s laws, and in particular we know very well Murphy’s laws about software . My favorite one says “Nothing ever gets built on schedule or within budget”. There’s not much you can do about this except getting to learn and know as much as possible about the business domain that your software is called to mimic. We ultimately write software to reproduce processes of the real world. We must know them, we must fully understand the mechanics of the domain, we must know the language being spoken by experts and we need all of these to make sense of requirements and plan software.   

At first, I’d say that software architects and lead developers are the ideal target of this class. But then I’d even say that nothing in this class is completely new in the sense that most architects may have heard about most of the topics if not practiced. So I’d rather say that any developers of any type of .NET applications may find this class beneficial. Everyone who wants to be an architect may find this class helpful. Junior and senior developers won’t probably earn the same benefits from the class, but both I think will definitely gain a lot. To reinforce this point let me share an anecdote. It was my first talk in English; it was TechEd Europe 1999, I was excited and crazy and scared and I was hoping to find the room empty. But when I walked into the room I found that Don Box—the God of Windows/COM developers at the time—had already captured a front row seat. He was waiting for me and said “I’m here to learn from you.” “Don—I said—you’re like God. What do you expect to learn from me?” And he said a sentence that periodically resounds in my mind: “Dino, it’s all about perspective!” I’m sure everybody attending the class will gain his own unique and valuable perspective of the content—whether junior or senior developer.