Whatever CRUD means to you, architecturally speaking it is now dead. CRUD is dead? Long live CRUD, then. A more abstract approach to software design and development, summarized by the CQRS/ES acronym, has been around for a quite some time now. Many have coded it already and shared their experience and each did it in a kind of unique and personal way. It’s about time, however, we standardize to a few reusable patterns.
Here’s where “Architecting for the .NET Platform — UX, DDD, Events, Polyglot persistence” fits is.
Three days of SDD Deep Dive are enough to see a few of these CQRS/ES patterns in action within a new framework in development that aims at bringing the same smooth and familiar sense of programming of old CRUD to the next step. Join me then and I promise that in three days you’ll take a tour of the “known” (requirements, estimates, domain analysis, modeling, coding) and how it needs to change in order to remain mainstream and largely used.
Architecting for the .NET Platform — UX, DDD, Events, Polyglot persistence is a 3-day workshop taking place in London 8-10 November 2016. Register now. (Save £200 if within Sept 23).
When it comes to designing software, the first step is getting familiar with the domain. The second step is modeling the domain into a more and more formal set of statements up to diagrams and code. To model the domain, Eric Evans suggested the use of something he called the “ubiquitous language”. In spite of the evocative name, it’s something as simple as a glossary of terms including verbs, names, adjectives, adverbs, form the pillars of a language being used in all written and spoken communications between all parties involved in the software project. The primary goal of the ubiquitous language is avoiding misunderstandings and assumptions on both ends—stakeholders and development teams. Put another way, the ubiquitous language aims at making any use of a given word or expression within the project absolutely crystal-clear and unambiguous. When that word or expression is used, therefore, there should be all around the absolute certainty that it was understood and in the right and expected way.
And now let me share a personal note to emphasize the vital role that a ubiquitous language plays in life and subsequently in software.
My wife had nose surgery a couple of months ago. In particular she had turbinectomy, namely the surgical reduction of her quite enlarged turbinate. When we discussed pros and cons, the doctor (aka, the development team) said clearly that it was a routine surgery with the hardest part of it coming in the following weeks once the patient had been sent back home. To illustrate possible complications, the doctor used the expression “nasal crusting” to be removed in a clinic or any sort of doctor’s office, in case of trouble. He also said that sometimes patients do so well that they never show up to remove nasal crusting.
We confused the term “crust” and“scab” and that was reasonable too as both usually happen when you have nose surgery. Now, crust refers to a mix of dried mucus, blood and dead tissue that altogether form a solid block as big as a small finger. A piece of crust is stuck inside the nose with barely any chance to get rid of it without a doctor. Scab is simpler matter as it’s a superficial cover on a wound of any type. You have scabs in the nose whenever you get significantly cold for example.
To make things worse, in Italian we use the same word for both crust and scab. To cut a long story short, my wife enjoyed two weeks of trouble until we called the doctor and he promptly removed the crust and explained us that crust is not the same as scab.
How many times did that happen to you software-wise? That’s just the ubiquitous language in action.
I doubt many CTOs go to technical developer’s conference where they can witness cool demos like a vNEXT web site deployed to a memory stick and installed on the clean machine of an unaware attendee. Such a demo is definitely cool and just the kind of thing done to excite developers. But I’m afraid it won’t appeal CTOs as much.
As a result, there are two options ahead for a CTO to consider.
1) Ignore vNEXT entirely and do business as usual: same frameworks, same coding experience, same deployment options, no additional features. You don’t lose anything of what you have and can do today;
2) Embrace vNEXT entirely as if it really were (and it is not) a breaking platform with no backward compatibility;
vNEXT lays the ground for Microsoft.NEXT. It inherits enough from current, adds some breaking changes, sets new goals and direction. Like it or not, you won’t be able to ignore vNEXT for too long. vNEXT is where the business of software seems going these days. I invite you to consider vNEXT as a completely new family of products and frameworks regardless of framework versioning and actual compatibility. Code is–to a good extent–backward compatible; the approach to development is not.
Imagine the .NET vNEXT as a family of frameworks to base future development on. I’d even hope that names (ie, ASP.NET) are completely changed to smooth the transition and give the right perspective of what’s going on.
- .NET Web is the modernized HTTP pipeline that includes MVC6/WebPages for HTML, Web API for JSON, SignalR for realtime and relies on OWIN for in-out communication and EF7 for data access.
- .NET Native is the revisited baseground for Windows Store and Windows Phone apps.
- .NET Core is the latest .NET Framework that is just v4.5.3.
- .NET for Devices is the framework for micro-devices.
- Possibly more frameworks coming.
It goes without saying that this is the way I see it and would explain it to fellow CTOs and architects. I didn’t mention the cloud. The cloud is the substrate of everything around vNEXT. You can have the cloud or not; whatever you can do in vNEXT can be done through the cloud too.
After a long labour it finally delivered! At last, at least the Kindle edition of Microsoft .NET: Architecting Applications for the Enterprise (NAA4E) is out available for download. The book has 14 chapters two of which should be made available for free at some point in the coming weeks. Free chapters are “Discovering the Domain Architecture” and “Introducing CQRS”.
All in all, they are the two most relevant–because most inspiring chapters of the entire book. If there’s one primary purpose this book serves that is the purpose of separating the idea of DDD as an approach to development from the idea of having a domain object model. The two things are fused together in the Eric Evans “blue book” but the same author revisited the perspective in a later session back in 2009. For what we can say, the majority of developers missed this point. We say that DDD as a guideline is key to everybody and every project; the domain model (entities, aggregates, value objects) is just one of the many supporting architectures. CQRS is yet another supporting architecture and comes up just to fix the open/weak points of Domain Model. Enjoy! And stay tuned with latest news on Facebook. Like us at facebook.com/naa4e.
Source code of the book is http://naa4e.codeplex.com.
Andrea Saltarello and I are slated for two breakout sessions this fall at MS TechEd Europe. In addition, I’m going to run a workshop on Monday October 27. More details here.
Architecting and Implementing Domain-Driven Design Patterns with .NET
Domain-driven Design (DDD) is an approach to software design and development that focuses on the analysis of the business domain and uses ad hoc tools such as the ubiquitous language to split the business domain into distinct subdomains, each of which becomes a bounded context and requires its own architectural approach. After a brief introduction on the foundation of the DDD approach (mostly ubiquitous language and bounded contexts), we’ll focus on a reference .NET application and discuss its implementation of the Domain Model pattern (aggregates, POCO domain entities, value objects, domain services) while contrasting the use of anemic domain models. Next, we’ll compare the Domain Model implementation to the CQRS pattern. In a CQRS architecture, the business logic of the application is expressed in terms of command and events and queries take place on a physically segregated stack. Along the way, we emphasize the role and structure of the persistence layer and touch on cross-cutting concerns (scalability, caching, security) and dependency injection to protect domain logic from infrastructure technologies. Overall, this session presents the state-of-the-art for enterprise application architecture and development in .NET. By attending this session, you’ll get a global vision of the fundamental DDD patterns and see them implemented in reference application.
Applying CQRS and Event Sourcing in .NET Applications
When you use the Event Sourcing pattern in a .NET application, your data source just consists of persisted events. You don’t likely have a classic relational data store; all you store are events, and you store them sequentially as they occur in the domain. As you can guess, persisting events instead of a domain model has a significant impact on the way you organize the back end of the system. Event persistence weds well with a strategy of separating the command and query stacks (CQRS), and with the idea that distinct databases are used to save the state of the application and expose it to the presentation layer. When you add ES to a system, you just change the structure and implementation of the data source. In this talk, we just develop a mini-ERP application that works out of distinct command and query stacks and persists just events. We also discuss how to rebuild state from events and see when replaying events is an option and when you’d better use up-to-date or partial data snapshots. Overall, this session presents a concrete example of a cutting-edge application architecture that for its inherent simplicity and maintainability is gaining momentum whether you have a complex business scenario to scale out or a just a CRUD system a bit more sophisticated than plain CRUD.
See you there! And check out related book at facebook.com/naa4e. By the way, why don’t you like the page? 🙂
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.