If you aren't excited about modern Windows development, you will be after you read this book. Learn WinUI 3.0, by Alvin Ashcraft, is a comprehensive and engaging tour of the latest version of the WinUI framework.

Previously, I discussed our intention to maintain a separation between Presentation (View Model), Domain, and Persistence entities in our architecture. I talked about some of the difficulties this design decision presents, and how we can mitigate those obstacles using an elegant, methodical entity-mapping strategy. In this blog entry, I build off of that discussion and elaborate on some of the high-level architectural patterns which emerge as a result. This is especially relevant if you are using CQRS, although that is not a prerequisite, and these patterns will apply just as readily to other approaches, including traditional N-layered architectures.

In this long-overdue entry, we’re going to circle back and discuss the importance of keeping a separation between various entity types within a DDD application, the challenges that presents, and elegant mapping strategies we can use to make it work. First, however, I’m going to briefly touch on some key enhancements to the C# language that were released with version 9, and how those influence our architecture from a Domain-Driven Design perspective. Alongside the blog entry in which I laid out my Clean DDD architectural template in detail, this is one of the most important that I’ve written to date, so I hope you enjoy it and find the knowledge from this to be useful.

In this blog entry I’ll go over using custom ASP.NET Core middleware to catch various kinds of exceptions so that we can return the proper HTTP status code to the user’s browser. At the Angular side we’ll take advantage of these status codes in order to direct the user to the appropriate pages on an error—an "unauthorized" page or general error page—or simply display a notification. This is one approach to handling server exceptions which are prone to "bubble up" from lower layers of the stack, such as the Application and Domain layers, and elegantly updating the UI.

In this blog entry we will evolve our solution and the data model behind it, so that we can begin to see how user requests and interactions operate against a multitenant system. We’ll start by refactoring the persistence interfaces and implementations to make the solution more scalable in a split-stack CQRS architecture. Alongside this change, I’ll show you how you can use both Dapper and Entity Framework Core inside a single transaction/unit of work. Then we’ll add some new EF Core entities corresponding to the tenants and customers of our SaaS product. Finally, we’ll perform some cleanup across the data model classes so that the Persistence layer is more robust.