According to Wikipedia, the expression “egg of Columbus” refers to a brilliant idea that seems so simple and obvious after the fact. The same idea that at some point seems doable by everybody was out of reach before someone actually did it.
CQRS is the latest egg of Columbus in software architecture. Once smart people like Bertrand Meyer, Martin Fowler, Greg Young, Udi Dahan had formalized it at different times and through different steps, it sounds like it is such an easy thing that nobody needs credits for that. As I see things, one of the reasons why CQRS doesn’t sound so exoteric as DDD is that it is really simple and effective to the point that is seems to be a natural element of software development.
CQRS in a way fights the idea that it is always necessary build a complex and convoluted domain model that encompasses all possible actions within a given domain. CQRS applies an old strategy that rulers of the past used extensively: Divide-et-Impera. It does that by splitting commands from queries and inviting architects to design both through distinct stacks. Stacks are distinct in all regards–technology as well as patterns.
This year, I’ll have a full-day precon workshop at Microsoft TechEd Europe in Barcelona (Monday, October 27) just dedicated to .NET architecture. The title is “Architecting .NET Solutions for the Enterprise” and it lays the ground for a CQRS-inspired design and implementation starting from a deeper analysis of DDD. You’ll see a reference application–an online store–first designed and implemented as a canonical DDD project. Next, you’ll see the same application rebuilt using commands, events and queries as distinct stacks. Here’s the list of modules:
- Discovering the Domain Architecture: ubiquitous language and context mapping.
- The Domain Model Supporting Architecture: essentials of the Domain Model pattern and role and structure of the domain layer in a multi-layer architecture.
- The CQRS Supporting Architecture: task-based implementation in the command stack and plain LINQ-to-Entities queries in the query stack.
- Event Sourcing: storage of events instead of working out a full-fledged domain model and persisting it through an O/RM.
- UX-First Design: the key message of this workshop is that today the UX is the most important aspect of any software. Focusing on UX leads to understanding clearly and unambiguously the tasks the application must perform.
Most of the content of the workshop is inspired by the freshly released 2nd edition of the NAA4E book “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) that I authored hands down with Andrea Saltarello. To stay in touch, have a look at our Facebook page.
PS: By the way, we’ll be releasing the reference applications in the book (and discussed in the workshop) on Codeplex sometime soon!
This is one of those topics that all developers use nearly every day without being often aware of. Now it’s quite rare that you need to deal with hash code and override Equals. The more you do object modeling (and domain modeling) the more you need it.
The .NET Framework strongly recommends that whenever you override Equals you also override GetHashCode. But why is it so?
Method Equals is always used when equality is checked explicitly such as when your code calls Equals directly or uses the == operator. GetHashCode is not involved in the equality assessment process. Subsequently, its implementation doesn’t impact the equality evaluation. Yet, you get a compiler warning if you override Equals but not GetHashCode.
GetHashCode comes into play only if your objects are going to be stored within hash tables or used as dictionary keys. In this case, the .NET Framework uses the value returned by GetHashCode to find the corresponding entry in the hash table or dictionary. Two object instances that are the same object according to Equals but return different values according to GetHashCode will never be considered equal. As a result, different values will be picked from the hash table or dictionary.
When your objects appear as public objects in a class library, you simply have no guarantee that they will never be used within hash tables or as dictionary keys. For this reason, it is strongly recommended that you override both methods to ensure that two objects that are equal according to Equals also return the same GetHashCode value. The returned value doesn’t matter as long as it’s the same. In light of this, why not simply making GetHashCode return a constant value in all cases?
When GetHashCode returns the same value for two objects you get a collision and Equals is called to ensure the objects are the same. A performance goal is of course minimizing the number of collisions giving each object with a unique combination of values a different hash code.
Finally, note that the hash code should never change during the lifetime of an object. For this to happen, only immutable properties should be used to calculate the code. This fits perfectly with guidelines for entities and value objects.
As I progress on the second edition of bestselling Microsoft .NET: Architecting Applications for the Enterprise (NAA4E). I learn more and more about Domain-driven Design (DDD) and, above all, I’m seeing it through the lens of a different perspective. Instead of just blindly applying my understanding of it built on top of tips, tricks and advice collected here and there, I’m truly learning it from the foundation. And guess what? I can now fully answer the following (simple but tricky) question I got on LinkedIn. The question apparently is completely unrelated to DDD. At a deeper look, though, it’s DDD that is related to nearly every aspect of software architecture; even when it could lead to a CRUD software.
For ASP.NET web applications requiring only CRUD operations(like automating paper forms), do you think using Entity Framework is slower than using DAL, BAL and presentation layer using stored procedures? Is using EF with stored procedure the right solution for this?
There are two distinct parts in DDD. You always need one; and may sometimes happily ignore the other.
- DDD has an analytical part that sets an approach to express the top level architecture of the business domain in terms of bounded contexts.
- DDD has a strategic part that relates to the definition of a supporting architecture for the identified bounded contexts. The default supporting architecture is Domain Model. A quickly emerging alternate option–in many ways fully replacing Domain Model–is CQRS.
The real added value of DDD lies in using the analytical part to identify bounded business contexts. This is the part of DDD that relies on the ubiquitous language–the key factor.
Once this has been done, the next problem is identifying the ideal way to tackle (read, implement) each bounded context. In doing so, you can certainly consider the two recommended supporting architectures of DDD. You can even–probably should–consider event sourcing in combination with CQRS.
But, in the end, it’s all about finding the ideal way to meet requirements in a well-understood business context. So “ideal” should be measured against actual business requirements and NOT against ideal principles of code elegance, cleanliness, future extensibility, readability and the like. If, as in the question, all you need is CRUD and you need it quickly and probably don’t need it after a short amount of time, by all means go with a quick ASP.NET CRUD and stored procedures.
Stay tuned on Facebook for the progress of #NAA4E!
A few weeks ago, Andrea and I started working on a new edition of teh book Microsoft .NET: Architecting Applications for the Enterprise which will likely be available in 2014—hopefully in the first half. We aim at another 300 pages book with a completely different table-of-contents. In particular, the table-of-contents reflects our experience on real projects and the outline of software design classes we’ve been teaching lately. The full story has been published today by MS Press.
We plan to publish updates primarily on this blog and Andrea’s blog and link them from within the Facebook page where we invite you to share comments, suggestions, tips and any kind of feedback. If you tweet, please use #naa4e. More official news will also appear on MS Press blog.
In the book we propound a revised layered architecture (presentation, application, domain and infrastructure) and a sort of revolutionary approach to design that starts from presentation and addresses multi-device concerns, separation of concerns, as well as the Big Ball of Mud problem at its root.
- Mechanics of software projects
- Principles of software design
- Writing software of quality
- The Presentation Layer
- The Mythical Business Layer
- Introducing Domain Modeling
- Implementing Domain Modeling
- Introducing CQRS
- Implementing CQRS
- Introducing Event-sourcing Models
- Implementing Event-sourcing Models
- The Infrastructure Layer
Let us know if you’re interested in reviewing some chapters and feel free to share suggestions. We encourage you do that through the Facebook page .
I could be wrong but it really seems that I haven’t been in the US for two years now. First week of October, I’ll be back in Las Vegas, proud speaker at the DevConnections show. I will have quite a busy schedule, with three breakout sessions in two days and, to finish with the flourish, a mobile architecture full-day workshop the Friday, Oct 4. Here’s my schedule:
I just want to spend a few extra keystrokes here to call your attention on the workshop. It’s about ASP.NET MVC 4 and Bootstrap; you’ll get a complete solution that works beautifully on smartphones, tablets and PCs and IS NOT primarily based on responsive templates.
What??? Read the abstract:
Usually a solution is sought for a clear and well-defined problem. In mobile, instead, sometimes it seems that we’re looking for solutions without having first clarified what the problem is. “Mobile”, however, is a term that is quickly getting obsolete replaced by the term “device”. Any solution that involves mobile devices should be planned for a multitude of devices. This basic fact changes the approach to the design of the presentation layer (and to a good extent, also the application layer) putting the user experience on top of everything and, at least for new systems, taking precedence over domain and infrastructure. In this demo-laden workshop, we’ll first focus on multi-view client-side aspects such as Responsive Web Design and related frameworks such as Bootstrap and AngularJS. Next, we will identify possible pitfalls of Responsive Web Design and ways to work around them. In doing so, we’ll introduce server-side feature detection and device capabilities.
Key passages in the text:
- We’re looking for solutions without having first clarified what the problem is
- Changes the approach to the design of the presentation layer (and to a good extent, also the application layer
Being responsive is obvious and foregone. There will be no point in being responsive in a few months. You must be responsive.
I’d say you must work to provide a responsive experience much more than a responsive design. This is a sort of Copernican revolution in software architecture. And event-sourcing (no matter how implemented, DDD/CQRS/Transaction Script) is another REAL revolution–this one truly the biggest thing after object-orientation.
I suggest you also attend Stephen Bohlen sessions as well if this topic is catching you.