𝗗𝗲𝗰𝗹𝗮𝗿𝗮𝘁𝗶𝗼𝗻 𝗣𝗮𝘁𝘁𝗲𝗿𝗻 — A Friendly Approach to Cleaner .NET Code

One of the patterns I keep coming back to in real-world .NET projects is the Declaration Pattern.
It’s simple, expressive, and helps your code reflect intent instead of getting bogged down in control flow.

If you’ve ever looked at a messy method full of if/else branching and repeated logic… you’ll appreciate how declarative design brings clarity.

What It Really Means

The Declaration Pattern is all about defining what you want, not how to do it.

You express rules, conditions, workflows, or configurations in a declarative way, and let the system handle the underlying mechanics.

It’s the same idea behind SQL or LINQ — describe the outcome, not the procedure.

Why It Helps

• Your code becomes easier to read
• Business rules become reusable blocks
• No more giant conditional statements
• Testing becomes straightforward
• New rules can be added without touching old ones

A Real-Life .NET Example (Business Rules Without If/Else Hell)

Let’s say you’re building a discount system for an e-commerce platform.

Traditional Imperative Approach

Messy and grows out of control:

public decimal CalculateDiscount(User user)
{
    decimal discount = 0;

    if (user.IsPremium)
        discount = 0.15m;
    else if (user.Age > 60)
        discount = 0.10m;
    else if (user.JoinedDate < DateTime.Now.AddYears(-5))
        discount = 0.05m;

    return discount;
}

Soon, you’ll have dozens of conditions, and maintenance gets painful.

Declarative Version (Clean & Scalable)

public class DiscountRule
{
    public Func<User, bool> Condition { get; set; }
    public decimal Rate { get; set; }
}

var rules = new List<DiscountRule>
{
    new() { Condition = u => u.IsPremium, Rate = 0.15m },
    new() { Condition = u => u.Age > 60, Rate = 0.10m },
    new() { Condition = u => u.JoinedDate < DateTime.Now.AddYears(-5), Rate = 0.05m }
};

public decimal CalculateDiscount(User user)
{
    var matchedRule = rules.FirstOrDefault(r => r.Condition(user));
    return matchedRule?.Rate ?? 0m;
}

Here you’re declaring rules instead of writing logic.

• No sprawling condition chains
• Rules live in a simple list
• Adding a new rule = adding one line
• Business logic is readable even to non-technical stakeholders

Common Use Cases in .NET

• Authorization rules (policies in ASP.NET Core)
• Validation (FluentValidation is fully declarative)
• Workflow definitions
• Feature toggles
• Pricing, discounting, scoring engines
• ETL transformations
• Specification pattern
• Minimal APIs with attributes

It’s one of those quiet patterns that make a real difference in production systems.