DDD+CQRS - Should I always check if the Databases are online?

Question

I'm developing an intranet application and I'm trying to use some concepts from Domain Driven Design (DDD) and Command and Query Responsibility Segregation (CQRS) in .NET Core, with EFCore.

But, to avoid weird exceptions from the API, on every Command and on every Query I'm first checking if the database is online (using DbContext.CanConnect()) and I send a pretty message to the user in case it's not. Instead of throwing some EF exception saying the database could not be found. I'm using a generic ApiResponse<T> that has .Data and .ErrorMessages to always return the same way from the API.

Is it the recommended approach? Or should I catch the exception somewhere else and return the message to the user from this other place? Or should I actually throw the exception from the API?

Elaborating a bit on my ideas: I'm thinking of using a .net Core Middleware to avoid this repetition and check the database prior to even getting to the Command/Query handler. Is it a good solution to the repetition?

EDIT: I realize there seems to be multiple questions in here, but my main concern is:

What's the DDD+CQRS recommended approach for this scenario where I'm repeating the same code (to check if DB is online) on every Command and on every Query?

Answer 1

The idea of DDD is to design the system according to the business domain. Databases are part of the solution domain, not the business domain. Hence, the design should be as agnostic to your choice of backing service as possible.

Whoever sends a business message (command or query) shouldn't know how the data is processed. Whether it's persistent or not, if the the storage is a database or a file, remote or local, relational or not—and, of course, the error recovery strategy. That knowledge is a separate responsibility. Typically, we use intermediaries to make this decoupling, with event buses being a popular choice.

As for the backing service itself, it shouldn't tell anyone else if it makes these checks or not. Its contract might specify how it will resolve unavailability problems e.g., drop the messages, X number of retries or storing them locally. The point is that the caller has delegated the responsibility of persistence and thus shouldn't do any result-checking.

Side note: Checking for availability is one of the most common time-of-check to time-of-use mistakes, so be careful. A more robust approach is to acknowledge that failures will happen and figure out what sort of action is most appropriate in that situation.