From ca0c2f3d822bc47dba868738ed9b3181e6386a07 Mon Sep 17 00:00:00 2001 From: Tom Brereton Date: Tue, 3 Dec 2024 11:28:11 +1100 Subject: [PATCH] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 3d18d1e..3f33db6 100644 --- a/README.md +++ b/README.md @@ -44,6 +44,7 @@ I want to have a starter template for building Dotnet Apis. Things that are impo ## Architectural Decision Records - Have a thin endpoint/controller and move the logic into a handler/service class so it's (1) unit testable and (2) decoupled from the endpoint framework to ease with refactoring e.g. moving the handler to a `Core` or `Application` project. - (Exploring) Use [Result](https://www.milanjovanovic.tech/blog/functional-error-handling-in-dotnet-with-the-result-pattern) objects for control flow instead of exceptions. In common code paths like validation or business rules use Result.Failure() or Result.Success(); use Exceptions for situations like failed connection, out of memory, access array incorrectly +- Perform all validation you can in with Input Validation, i.e. the FluentValidator. For validation on business rules i.e. if x is 3, then y can only be 5, or no duplicate calendar names, perform this in the Domain Entity. The Entity is an Aggregate, so it has all the information loaded in memory to perform these checks without reaching into the database again. ## Prerequisites