Skip to main content
Software Alchemy

The Art and Science of Software Development

Clean DDD Workflow

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.

Mapping Entity Types

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.

Global Exception Handling in ASP.NET Core and Angular

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.

Persistence, Tenancy, and the Data Model

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.

Architectural Template

This is the first in a multi-part series in which I will be building off the Foundational Concepts Series. My objective is to present actual, procedural steps that you can follow and apply to your own web projects using ASP.NET Core. As I present these steps, I will be updating the demo application accordingly, the goal being to evolve it into a working web application by the end of this series.

My objective is to demonstrate that Clean Domain-Driven Design works in modern web applications built on the ASP.NET Core stack. The desired end-product will be a multi-tenant SaaS product which can scale to accommodate complex business logic. I intend to revisit different areas of functionality in future blog series’, at which point we can make it more robust and enterprise worthy.