The Rule Pattern in C#, and Why It Works So Well with the Result Pattern Business rules have a bad habit of spreading everywhere. A little validation in a command handler, another check in a service, one more if in the entity, and before long the real policy of the system is buried under conditionals. The Rule pattern solves that by giving each business rule its own object and a clear name. In practice, this style is very close to what Fowler describes as the Specification pattern, especially when you start combining rules with AND, OR, and NOT. ( martinfowler.com ) At the same time, many of us do not want to throw exceptions for expected business failures. That is where the Result pattern fits naturally. Instead of throwing, we return a success or failure object that makes the outcome explicit to the caller. This is a common way to model expected failures in application code.…