cwoodruff/result-foundation

Context

Use this skill when implementing or extending the approved Result-based exception handling migration in the Domain layer. It applies when expected failures need to flow through Data, Managers, and Web without losing structured context.

Patterns

• Keep Error, Result, and Result<T> in src\MoreSpeakers.Domain\Models\, but expose them from the root MoreSpeakers.Domain namespace.
• Model creation after IdentityResult: factory methods live on non-generic Result instead of exposing public constructors.
• Use readonly struct for Result and Result<T> to stay additive and allocation-conscious on the hot path.
• Keep failure access explicit: success results throw if callers read Error, and failure results throw if callers read Value.
• Cover the public API surface in src\MoreSpeakers.Domain.Tests\ResultTests.cs, including success, failure, implicit conversion, and equality.
• When converting an existing vertical slice, let the slice interface own explicit Result signatures instead of inheriting generic IDataStore contracts that force sentinel returns.
• In DataStores, catch only expected persistence exceptions such as DbUpdateException; return typed Error codes for not-found/no-op outcomes and let unexpected exceptions propagate.
• In Managers, forward DataStore Result values unchanged unless adding boundary validation or input normalization that belongs above persistence.

Examples

• var ok = Result.Success();
• var saved = Result.Success(user);
• var failed = Result.Failure<User>(new Error("users.save.failed", "Unable to save the user.", ex));
• Result<Guid> id = Guid.NewGuid();

Anti-Patterns

• Do not expose public constructors for Result or Result<T>.
• Do not use sentinel values (null, false, empty collections) for expected failures once a Result-based path exists.
• Do not strip exception context when an Error can carry the underlying exception reference.