DEV Community: Oluwagbemileke Femi Oyeyoade

What Happens After Approval: Decoupling Side Effects with the Observer Pattern

Oluwagbemileke Femi Oyeyoade — Tue, 23 Jun 2026 11:42:35 +0000

Part 4 of 4: Emails, audit trails, one event handler that catches dozens of event types it's never heard of, transaction semantics, and where this fits among MediatR, Channels, and message brokers

Across this series, a strategy has gone from "one branch in a 50-case switch statement" to "a small, independently testable class, resolved without a switch statement (Part 2), and permission-checked without inline if blocks (Part 3)." By the time ApproveLeaveRequestWorkflowAction.ExecuteAsync finishes, it's done its actual job: validated the request, updated the record, committed the transaction, returned Result<Unit>.Success(Unit.Value).

There was one line in that method, all the way back in Part 1, that got a passing mention and nothing more:

await _eventPublisher.Publish(
    new LeaveRequestDecisionEvent(authenticatedUser.Id, leaveRequest.Id, request.IsApproved),
    token);

This article is about that line - and about everything that's allowed to happen because of it, without the strategy knowing any of it is going on.

The Problem: Approval Isn't Really "Done" When the Strategy Returns

In any real approval system, "the request was approved" is rarely the end of the story. Someone probably wants an email. Compliance almost certainly wants an audit trail - who approved what, when, from where. Maybe a dashboard needs a cache invalidated. Maybe a downstream system needs a webhook fired.

The tempting place to put all of that is right inside the strategy, after the commit:

await _context.SaveChangesAsync(token);
await transaction.CommitAsync(token);

// Now bolt on everything else that needs to happen...
await _emailHelper.SendLeaveDecisionEmail(leaveRequest, request.IsApproved);
await _auditLogger.LogApproval(authenticatedUser, pendingRequest);
await _cache.InvalidateAsync($"leave-requests:{leaveRequest.EmployeeId}");
// ...and whatever gets added next month

This is the same mistake Part 3 fixed for permission checks, showing up again in a new spot. ApproveLeaveRequestWorkflowAction was supposed to answer one question - what does it mean to approve a leave request? - and now it also has to know about email templates, audit log schemas, and cache key formats. Multiply that across 50+ strategies, and every one of them needs to remember to bolt on the same email/audit/cache calls, with no compiler-enforced way to guarantee nobody forgets.

There's also a subtler problem: the list of things that should happen after an approval is going to grow over time. A switch statement was a wall you'd hit when adding new approval types; this is the same wall, but for "things that should happen when any approval succeeds."

The Fix: Announce What Happened, Don't Decide What Happens Next

The Observer pattern (often implemented as a publish/subscribe mechanism) inverts the relationship. Instead of the strategy calling out to email, audit, and cache code directly, it publishes a description of what happened - an event - and stops. Anything that cares about that event can subscribe to it, with zero coupling back to the strategy that raised it.

The strategy's responsibility shrinks to one line: announce the event. It has no idea how many handlers are listening - zero, one, or ten - and it doesn't need to. Adding a new side effect later means writing a new handler, not editing the strategy.

The Event: A Plain Description of What Happened

An event is deliberately uninteresting - just data describing something that already occurred:

/// <summary>
/// Raised when a maker (HR admin) approves or declines a leave request.
/// </summary>
public sealed class LeaveRequestDecisionEvent : BaseHrAuditEvent
{
    public int EmployeeId { get; }
    public string EmployeeName { get; }
    public bool IsApproved { get; }

    public LeaveRequestDecisionEvent(
        int makerId,
        string makerUserName,
        int employeeId,
        string employeeName,
        bool isApproved,
        DateTime? timestamp = null)
        : base(makerId, makerUserName, timestamp)
    {
        EmployeeId = employeeId;
        EmployeeName = employeeName;
        IsApproved = isApproved;
    }

    public override string Description =>
        $"{MakerUserName} {(IsApproved ? "approved" : "declined")} the leave request for {EmployeeName}";

    public override AuditActivityEnum ActionType =>
        IsApproved ? AuditActivityEnum.ApproveLeaveRequest : AuditActivityEnum.DeclineLeaveRequest;

    public override HrTargetType TargetType => HrTargetType.LeaveRequest;
}

Note that it inherits from BaseHrAuditEvent rather than standing alone - that base class is the piece that makes the rest of this article work, so it's worth looking at directly:

/// <summary>
/// Base class for all HR audit events. Contains the metadata every audit
/// entry needs, regardless of what specific action occurred. Immutable.
/// </summary>
public abstract class BaseHrAuditEvent
{
    public int MakerId { get; }
    public string MakerUserName { get; }
    public DateTime Timestamp { get; }

    /// <summary>Human-readable description. Every derived event must supply one.</summary>
    public abstract string Description { get; }

    /// <summary>The category of action performed (Approve, Decline, Create, ...).</summary>
    public abstract AuditActivityEnum ActionType { get; }

    /// <summary>The kind of entity this event concerns (LeaveRequest, RoleChange, ...).</summary>
    public abstract HrTargetType TargetType { get; }

    protected BaseHrAuditEvent(int makerId, string makerUserName, DateTime? timestamp = null)
    {
        MakerId = makerId;
        MakerUserName = makerUserName ?? throw new ArgumentNullException(nameof(makerUserName));
        Timestamp = timestamp ?? DateTime.UtcNow;
    }
}

Every specific event - LeaveRequestDecisionEvent, RoleChangeDecisionEvent, EmployeeOnboardingDecisionEvent, and 47 more - inherits from this same base. Each one knows how to describe itself (Description), classify itself (ActionType, TargetType), and carries whatever extra data is specific to it. None of that is the interesting part yet. The interesting part is what's about to subscribe to it.

Two Handlers, Two Very Different Subscriptions

Here's where this gets genuinely useful: you can write a handler that subscribes to one specific event type, and a handler that subscribes to the base event type - and the second one will automatically receive every event derived from that base, including ones that don't exist yet.

Handler #1 - specific, narrow, knows exactly what it's for:

/// <summary>
/// Sends a notification email when a leave request decision is made.
/// Subscribes only to LeaveRequestDecisionEvent - nothing else.
/// </summary>
public class LeaveRequestDecisionEmailHandler : IEventHandler<LeaveRequestDecisionEvent>
{
    private readonly ITemplateEmailNotificationHelper _emailHelper;
    private readonly HrEmailConfigs _emailConfigs;
    private readonly ILogger<LeaveRequestDecisionEmailHandler> _logger;

    public LeaveRequestDecisionEmailHandler(
        ITemplateEmailNotificationHelper emailHelper,
        IOptions<HrEmailConfigs> emailConfigs,
        ILogger<LeaveRequestDecisionEmailHandler> logger)
    {
        _emailHelper = emailHelper;
        _emailConfigs = emailConfigs.Value;
        _logger = logger;
    }

    public async Task Handle(
        LeaveRequestDecisionEvent @event,
        HrContext context,
        CancellationToken cancellationToken)
    {
        var action = @event.IsApproved ? "Approved" : "Declined";
        var subject = $"{action} Leave Request: {@event.EmployeeName}";

        var keyValuePairs = new Dictionary<string, string>
        {
            { "EmployeeName", @event.EmployeeName },
            { "Decision", action },
            { "ApprovedBy", @event.MakerUserName }
        };

        var emailRequest = new EmailModel
        {
            MailSubject = subject,
            MailTo = _emailConfigs.LeaveRequestNotificationAddress
        };

        await _emailHelper.SendMail(
            emailRequest,
            relativeTemplatePath: _emailConfigs.LeaveDecisionTemplate,
            keyValuePairDictionary: keyValuePairs,
            cancellationToken);

        _logger.LogInformation("Sent leave decision email for {Employee}", @event.EmployeeName);
    }
}

Nothing surprising here - it does one specific thing for one specific event, and would never be asked to handle RoleChangeDecisionEvent or anything else.

Handler #2 - generic, subscribes to the base type, handles everything:

/// <summary>
/// Writes an audit trail entry for ANY HR audit event. Subscribes to
/// BaseHrAuditEvent - every derived event type is routed here automatically,
/// with no changes needed when a new event type is added.
/// </summary>
public class HrAuditEventHandler : IEventHandler<BaseHrAuditEvent>
{
    private readonly HrContext _context;
    private readonly ILogger<HrAuditEventHandler> _logger;

    public HrAuditEventHandler(HrContext context, ILogger<HrAuditEventHandler> logger)
    {
        _context = context;
        _logger = logger;
    }

    public async Task Handle(
        BaseHrAuditEvent @event,
        HrContext context,
        CancellationToken cancellationToken)
    {
        var auditTrail = new HrAuditTrail
        {
            MakerId = @event.MakerId,
            ActionType = @event.ActionType,
            TargetType = @event.TargetType,
            Timestamp = @event.Timestamp,
            Description = @event.Description
        };

        await _context.HrAuditTrails.AddAsync(auditTrail, cancellationToken);
        await _context.SaveChangesAsync(cancellationToken);

        _logger.LogInformation("Audit record saved for Maker={MakerId}: {Description}",
            @event.MakerId, @event.Description);
    }
}

This handler has never heard of LeaveRequestDecisionEvent. It doesn't need to. It was written once, against the base type, and it will run for every one of the 50+ derived event types this series keeps referring to - including ones written after this handler was deployed.

How: The Publisher Walks Up the Inheritance Chain

This only works because of how the publisher resolves handlers. A naive pub/sub implementation would look for handlers registered for the exact runtime type of the event and stop there - which would mean HrAuditEventHandler, registered against BaseHrAuditEvent, would never be found for a LeaveRequestDecisionEvent instance. The publisher has to deliberately walk up the type hierarchy:

private IEnumerable<Type> ResolveHandlerTypes<TEvent>(TEvent @event) where TEvent : class
{
    var eventType = @event.GetType();
    var handlerTypes = new List<Type>();

    while (eventType != null && eventType != typeof(object))
    {
        var handlerInterfaceType = typeof(IEventHandler<>).MakeGenericType(eventType);
        var resolvedHandlers = _serviceProvider.GetServices(handlerInterfaceType);

        handlerTypes.AddRange(resolvedHandlers.Select(h => h.GetType()));
        eventType = eventType.BaseType;
    }

    return handlerTypes.Distinct();
}

Walking through what happens for a LeaveRequestDecisionEvent:

The loop climbs the inheritance chain one level at a time - LeaveRequestDecisionEvent → BaseHrAuditEvent → object - checking at each level whether any handler is registered for that exact type. LeaveRequestDecisionEmailHandler is registered for the concrete type and only fires for that one event. HrAuditEventHandler is registered for the base type and fires for every single event that derives from it, because every one of them passes through BaseHrAuditEvent on the way up.

This is the entire trick. No event router needs a giant mapping of "which events go to which handlers." The relationship is implicit in the class hierarchy: derive from BaseHrAuditEvent, and the audit handler picks you up automatically, forever, without anyone updating a list.

Registering Both Kinds of Handler

The DI registration mirrors the distinction. Specific handlers and generic base-type handlers can even be scanned and registered in separate passes, which is useful if they need different lifetimes or have different startup costs:

// Handlers for the base audit event - these fire for every derived event type
services.Scan(scan => scan
    .FromAssemblyOf<BaseHrAuditEvent>()
    .AddClasses(classes => classes.AssignableTo(typeof(IEventHandler<>))
        .Where(t => t.GetInterfaces()
            .Any(i => i.IsGenericType &&
                      typeof(BaseHrAuditEvent).IsAssignableFrom(i.GenericTypeArguments[0]) &&
                      i.GenericTypeArguments[0] == typeof(BaseHrAuditEvent))))
    .AsSelf()
    .AsImplementedInterfaces()
    .WithScopedLifetime());

// Handlers for specific derived events - these fire for exactly one event type
services.Scan(scan => scan
    .FromAssemblyOf<BaseHrAuditEvent>()
    .AddClasses(classes => classes.AssignableTo(typeof(IEventHandler<>))
        .Where(t => t.GetInterfaces()
            .Any(i => i.IsGenericType &&
                      typeof(BaseHrAuditEvent).IsAssignableFrom(i.GenericTypeArguments[0]) &&
                      i.GenericTypeArguments[0] != typeof(BaseHrAuditEvent))))
    .AsSelf()
    .AsImplementedInterfaces()
    .WithScopedLifetime());

Worth being precise about what that second block's != typeof(BaseHrAuditEvent) check is actually selecting: not "events unrelated to auditing," but specifically handlers for the concrete derived types - LeaveRequestDecisionEmailHandler, RoleChangeDecisionEmailHandler, and so on - as opposed to the one handler registered against BaseHrAuditEvent itself. The two scans are splitting "the one handler that catches everything via the base type" from "the many handlers that each care about exactly one derived event," which is the same email-handler-vs-audit-handler split this article has been drawing all along, just expressed as a filter at registration time instead of left for the publisher to sort out at runtime. Separating them like this is mostly useful if the two groups genuinely need different treatment - different lifetimes, different startup wiring, or just keeping the registration code readable instead of one giant unfiltered scan that bundles every handler together regardless of what it subscribes to.

Both LeaveRequestDecisionEmailHandler and HrAuditEventHandler get picked up by this scan, in the same way Part 2's strategies were picked up without anyone naming them individually. Adding RoleChangeDecisionEmailHandler next month requires writing the class - nothing here changes.

The Full Picture

Put together, here's everything that happens after ApproveLeaveRequestWorkflowAction commits its transaction:

The strategy publishes one event and is done. It has no reference to LeaveRequestDecisionEmailHandler or HrAuditEventHandler - it couldn't even if it wanted to, since the publisher resolves handlers from the DI container at publish time, not from anything the strategy provides.

A Decision That's Easy to Miss: Where Does `Publish` Sit Relative to `Commit`?

Every code sample in this series so far has published the event after committing the transaction:

await _context.SaveChangesAsync(token);
await transaction.CommitAsync(token);

await _eventPublisher.Publish(new LeaveRequestDecisionEvent(...), token);

This placement isn't an accident, and it isn't the only valid choice - it's a business decision with real consequences, and it's worth making deliberately rather than by default.

Publish after commit means the database change is already permanent by the time any handler runs. If LeaveRequestDecisionEmailHandler throws because the email provider is down, that's unfortunate, but the leave request is still approved - the failure can't unwind anything, because there's nothing left to unwind. This is usually the right call for side effects that are genuinely secondary: a failed email shouldn't be allowed to undo an otherwise-valid approval. You'd typically want the publisher to catch and log handler exceptions in this mode rather than let them propagate, since by this point a thrown exception can't fix the data, it can only make the strategy's caller think something failed when the approval itself actually succeeded.

Publish before commit, inside the same transaction, is the other valid shape:

await _context.SaveChangesAsync(token);

// Publish while the transaction is still open
await _eventPublisher.Publish(new LeaveRequestDecisionEvent(...), token);

await transaction.CommitAsync(token);

Here, if a handler throws, the exception propagates back up through Publish, the catch block in the strategy catches it, and transaction.RollbackAsync(token) actually means something - the leave request approval and the failed side effect both get undone together. This is the right shape when a handler represents a condition that should be able to veto the entire operation. A concrete example: if HrAuditEventHandler failing to write an audit row is treated as unacceptable for compliance reasons - "we will not approve anything we can't also prove we approved" - then publishing before commit, and letting that handler's exception bubble up and roll back the transaction, is the correct design, not a bug.

A few more scenarios where this isn't just a compliance preference but closer to a correctness requirement:

Password reset. If completing a password reset publishes an event that also has to, say, invalidate every existing session token or notify a fraud-detection system, and that downstream step fails, you generally don't want the password considered "reset" while the old sessions are still silently valid - that's a security gap, not a minor inconvenience. Publishing before commit means a failure there rolls back the reset itself, so the user is left in a consistent state (still their old password, free to retry) rather than a half-applied one (new password active, but the security side effect silently never happened).
Financial postings. If approving a transaction also has to update a ledger balance or trigger a downstream reconciliation entry, and that update fails, committing the original transaction anyway can leave two systems disagreeing about money - exactly the kind of inconsistency that's expensive to detect and reconcile later.
Provisioning that depends on the side effect. If approving an onboarding request publishes an event that provisions a system account, and provisioning fails, you probably don't want the request marked "approved" while the employee has no account - better to roll back and let the maker retry the whole approval cleanly.

The common thread: publish-before-commit earns its complexity when the side effect isn't really secondary at all - it's a precondition the business considers part of "this operation actually succeeded," even though it's implemented as a separate handler for the sake of keeping the strategy's own code simple. The moment a failed handler would leave the system in a state someone would call "broken" rather than merely "incomplete," that's the signal to publish before commit instead of after.

Neither ordering is universally "more correct" - it depends on whether a given side effect is something the business considers optional-but-nice or non-negotiable. Pick one on purpose, per use case, rather than discovering the actual behavior the first time a handler fails in production. These can also be mixed: some events published before commit, where a veto matters, others fire-and-forget after commit, where it doesn't - there's no rule that every event in a system has to follow the same ordering.

Where This Sits Among Other Tools

Everything in this article - IEventPublisher, LocalEventPublisher, the handlers - is a deliberately small, in-process implementation: no message broker, no network hop, just C# resolving and invoking handlers from the same DI container the strategy itself is running in. That's a legitimate choice for this scale, and the alternatives below are what you'd reach for if the requirements changed.

In-process / synchronous, similar to what's shown here:

MediatR - by far the most common choice in .NET for exactly this in-process publish/subscribe shape. Its INotification + INotificationHandler<T> pair is functionally what BaseHrAuditEvent + IEventHandler<T> are doing here, with the wiring already built and battle-tested. Worth knowing: MediatR's built-in notification publishing dispatches to handlers registered for the exact type - the "walk up the inheritance chain to find a handler for the base type" trick this article leans on isn't out of the box; you'd still write that resolution logic yourself, or use a custom publisher.
.NET's own event/EventHandler delegates - the simplest possible option, with no DI scanning, no attributes, nothing. Reasonable for a small number of subscribers known at compile time; doesn't scale well to "dozens of handlers, dynamically discovered" the way this series needed.

Queue-based, for when the publisher shouldn't wait around:

Channels (System.Threading.Channels) - an in-process, in-memory queue. The strategy publishes by writing to a Channel<TEvent> and returns immediately; a separate background consumer (e.g. an IHostedService running a while (await reader.WaitToReadAsync()) loop) drains the channel and dispatches to handlers on its own schedule. This is the natural next step if the synchronous await _eventPublisher.Publish(...) call starts being a latency problem - for example, if the email handler is slow and you don't want the approval request to wait for it. The tradeoff: events live only in memory, so a crash between "written to the channel" and "consumed" loses that event. Fine for things like cache invalidation; risky for anything that absolutely must happen, like the audit trail.
RabbitMQ / Azure Service Bus / Amazon SQS - message brokers, for when events need to survive a process restart, be consumed by an entirely different service or codebase, or be retried automatically on failure. This is the right tool once "side effect" stops meaning "another class in the same process" and starts meaning "a different microservice needs to know this happened." It's also the natural evolution if your audit handler, email handler, or any other consumer needs guaranteed delivery - at-least-once semantics, dead-letter queues, retry backoff - none of which an in-memory publisher gives you for free.
Kafka - similar territory to the message brokers above, but suited to a different problem: very high event throughput, and consumers that care about replaying history or processing the same stream independently at their own pace, rather than each event being consumed once and discarded.

This series uses an in-process publisher because, at the scale of "a handful of handlers reacting to an approval decision within the same request," a queue or broker solves a performance and durability problem this system doesn't have - at the cost of real operational complexity (a broker to run, network calls that can fail, message serialization, consumer lag to monitor). The Observer pattern itself - strategy publishes, decoupled handlers react - is the actual idea. Whether it's implemented with a plain C# event, MediatR, a Channel, or a full message broker is a separate decision, driven by actual durability and latency requirements, not by default.

Why This Was Worth Four Articles

Step back across the whole series, and the same shape keeps repeating: take something that was one giant, tangled method, and split it along its actual seams - into pieces that can be written, tested, and changed independently, with the connections between them expressed as declarative metadata (attributes) rather than imperative logic (switches and inline if checks).

Part 1 split "what approval logic runs" away from "how a request gets routed."
Part 2 split "which strategy applies" away from "a central method that has to know about every strategy."
Part 3 split "is this allowed" away from "what does this action do."
Part 4 splits "this happened" away from "everything that should occur as a consequence."

None of these splits are free - there's more files, more indirection, more concepts to hold in your head than a single switch statement would require. That trade only pays for itself at scale, which is why a 50+ strategy production system is the right example for this series rather than a 3-case tutorial. Below a certain size, a switch statement is fine. Above it, these four patterns are what keep the system from collapsing under its own weight as approval type #51, #52, and #80 get added by however many developers end up touching this code over its lifetime.

Part 1 mentioned that the real system this series is based on reuses this exact same IHrApprovalStrategy / factory / Context machinery for a second, unrelated maker-checker relationship - privileged users managing other privileged users, with its own Super Initiator / Super Authorizer pair, resolved against a different TargetType on the same shared request table. That reuse is the actual test of whether the architecture is general, now that all four pieces are in view: nothing in the strategy interface, the attribute-based factory, the permission decorator, or the event-publishing mechanism had to know or care that a request was about managing an admin account rather than approving leave. Every one of these four patterns solves "route and execute a maker-checker decision," not "handle HR requests specifically" - and it transferred to a structurally similar but semantically unrelated problem without any changes to the shared infrastructure.

None of this - the order of Publish relative to Commit, or the choice between an in-process publisher, MediatR, a Channel, or a message broker - has a universally correct answer. They're implementation decisions downstream of a business question someone has to actually answer: should this side effect failing be able to undo the approval, or not? Get that answer first; the pattern and the tooling follow from it.

Decorating Strategies: Adding Permission Checks Without Touching Business Logic

Oluwagbemileke Femi Oyeyoade — Tue, 23 Jun 2026 11:42:17 +0000

Part 3 of 4: Cross-cutting concerns on top of Strategy, using the Decorator pattern

Part 1 of this series replaced a 50+ case switch statement with a family of strategy classes. Part 2 replaced a second switch statement - the one that would've picked which strategy to run - with attribute-based discovery via reflection. By the end of Part 2, adding a new approval type meant exactly one thing: write a class, decorate it with an attribute, done.

There's a gap that surfaces the moment your approval system distinguishes who is allowed to approve what. Approving an expense claim might be fine for any authorizer. Approving a role change to "Director" probably shouldn't be - that's a decision that might need a specific permission beyond just holding the authorizer role generally.

Two related but separate things are worth distinguishing here, since Part 1 covers one of them. Part 1 established that each role's actionable (pending) queue is filtered by the request's current stage - a reviewer's pending tab holds requests awaiting review, an authorizer's pending tab holds requests already reviewed and awaiting final sign-off, and a request that moves past the review stage drops out of the reviewer's pending tab (though the initiator and reviewer can still look it up elsewhere and see its full timeline - filtered out of what's actionable, not hidden from view). That's a stage-based visibility filter: it determines what's actionable in someone's pending list at a given moment, and it lives in the query that builds the list. This article is about a different, second layer: even for a request someone's role would normally let them act on, is this specific request one this specific person is allowed to approve? The role-based permission check below guards the approval action itself, at the moment it's attempted - a finer-grained gate than "which stage is this request at." The two checks live in different places because they answer different questions: the stage filter is about workflow sequencing, the permission check is about authorization.

Where does that action-level check go?

The Tempting Answer (And Why It's Wrong)

The obvious place is inside the strategy itself:

public async Task<Result<Unit>> ExecuteAsync(
    HrAdminUser authenticatedUser,
    HrApprovalRequest pendingRequest,
    BaseHrApprovalDecisionRequest request,
    CancellationToken token)
{
    if (!authenticatedUser.HasPermission(HrPermission.ApproveRoleChange))
    {
        return Result<Unit>.Failure("You do not have permission to approve role changes.");
    }

    // ...the actual approval logic from Part 1...
}

This works for one strategy. It stops working the moment you have to repeat it. If 15 of your 50+ strategies need a permission check, you now have the exact same if (!authenticatedUser.HasPermission(...)) block copy-pasted into 15 different classes - which means 15 places to update if the permission-checking logic ever changes, and 15 chances for someone to forget to add the check to strategy #16.

Worse, it muddies what each strategy class is actually responsible for. ApproveRoleChangeWorkflowAction was supposed to answer one question: what happens when a role change is approved? Now it's also answering a second, unrelated question: is this user even allowed to do that? Those are two different concerns, and Part 1's entire argument was that mixing concerns is what got us into the switch-statement mess in the first place.

Permission checking is what's usually called a cross-cutting concern - a piece of logic that applies across many otherwise-unrelated classes, rather than belonging to any one of them. Logging, caching, retry logic, and transaction handling are the other usual suspects. The right tool for layering a cross-cutting concern onto existing classes, without editing those classes, is the Decorator pattern.

The Idea: Wrap, Don't Modify

A decorator implements the same interface as the thing it's wrapping, holds a reference to the real implementation, and adds behavior before and/or after delegating to it:

From the outside, PermissionCheckingStrategyDecorator is an IHrApprovalStrategy - nothing calling it knows or cares that it isn't the real strategy. From the inside, it does one job (check the permission) and then forwards the call to whatever strategy it's wrapping:

/// <summary>
/// Wraps an IHrApprovalStrategy with a permission check. If the authenticated
/// user lacks the required permission, the inner strategy is never invoked.
/// </summary>
public class PermissionCheckingStrategyDecorator : IHrApprovalStrategy
{
    private readonly IHrApprovalStrategy _inner;
    private readonly HrPermission _requiredPermission;
    private readonly ILogger<PermissionCheckingStrategyDecorator> _logger;

    public PermissionCheckingStrategyDecorator(
        IHrApprovalStrategy inner,
        HrPermission requiredPermission,
        ILogger<PermissionCheckingStrategyDecorator> logger)
    {
        _inner = inner;
        _requiredPermission = requiredPermission;
        _logger = logger;
    }

    public async Task<Result<Unit>> ExecuteAsync(
        HrAdminUser authenticatedUser,
        HrApprovalRequest pendingRequest,
        BaseHrApprovalDecisionRequest request,
        CancellationToken token)
    {
        if (!authenticatedUser.HasPermission(_requiredPermission))
        {
            _logger.LogWarning(
                "User {UserId} lacks permission {Permission} for request {RequestId}",
                authenticatedUser.Id, _requiredPermission, pendingRequest.RequestId);

            return Result<Unit>.Failure(
                $"You do not have permission to perform this action.");
        }

        return await _inner.ExecuteAsync(authenticatedUser, pendingRequest, request, token);
    }
}

ApproveRoleChangeWorkflowAction from Part 1 doesn't change at all. It still has no idea permission checking exists. The decorator sits in front of it, intercepting the call, and only forwards to the real strategy if the check passes.

The Part That Makes This Actually Scale: Declaring Permissions, Not Wiring Them

A decorator that's manually constructed for one strategy isn't an improvement over inline checks - it's the same logic, just in a different file. The win only materializes if applying the decorator to 15+ strategies doesn't require 15+ lines of setup code somewhere.

This is solved the same way Part 2 solved strategy discovery: an attribute that lets each strategy declare what it needs, instead of something else having to know:

[AttributeUsage(AttributeTargets.Class, AllowMultiple = true, Inherited = true)]
public class RequiresHrPermissionAttribute : Attribute
{
    public HrPermission Permission { get; }

    public RequiresHrPermissionAttribute(HrPermission permission)
    {
        Permission = permission;
    }
}

Now a strategy that needs gatekeeping just adds the attribute, on top of the routing attribute from Part 2:

[HrWorkflowStrategy(HrTargetType.RoleChange, HrApprovalActionType.Approve)]
[RequiresHrPermission(HrPermission.ApproveRoleChange)]
public class ApproveRoleChangeWorkflowAction : IHrApprovalStrategy
{
    // ...unchanged business logic...
}

A strategy that doesn't need a permission check - say, an employee submitting their own leave request for review - simply doesn't carry the attribute, and is never wrapped at all. The decorator becomes opt-in, declared per-class, with zero central configuration listing out which strategies need protecting.

Tying It Together in the Factory

Recall the factory from Part 2: it resolves a strategy type from its routing attribute, then asks the DI container for an instance. That's exactly where the decorator gets applied - after resolution, before the strategy is handed back to the caller:

public IHrApprovalStrategy Resolve(
    HrTargetType targetType,
    HrApprovalActionType actionType,
    ApprovalRequestStatus? status = null)
{
    if (!_strategyCache.TryGetValue((targetType, actionType, status), out var strategyType) &&
        !_strategyCache.TryGetValue((targetType, actionType, null), out strategyType))
    {
        throw new InvalidOperationException(
            $"No strategy found for TargetType={targetType}, ActionType={actionType}, Status={status}");
    }

    var strategy = (IHrApprovalStrategy)_serviceProvider.GetRequiredService(strategyType);

    var requiredPermissionAttr = strategyType.GetCustomAttribute<RequiresHrPermissionAttribute>();

    if (requiredPermissionAttr is null)
    {
        return strategy; // No permission requirement declared - return as-is.
    }

    // Wrap it. The caller still just sees an IHrApprovalStrategy.
    return ActivatorUtilities.CreateInstance<PermissionCheckingStrategyDecorator>(
        _serviceProvider, strategy, requiredPermissionAttr.Permission);
}

ActivatorUtilities.CreateInstance constructs PermissionCheckingStrategyDecorator through the DI container, but lets you pass in extra constructor arguments (the strategy instance and the required permission) that aren't themselves registered services. The container fills in ILogger<PermissionCheckingStrategyDecorator> from its own registrations and slots in the two values you supplied - full DI resolution without registering a decorator instance for every possible inner strategy.

The full resolution flow now looks like this:

And the calling code - the service method from Parts 1 and 2 - doesn't change by a single character. It still just calls Resolve(...), wraps the result in HrApprovalStrategyContext, and invokes it. It has no idea whether what comes back is a bare strategy or a decorated one, and it doesn't need to.

Why This Is Worth the Extra Layer

For one strategy, this is over-engineering - a plain if statement would do. The decorator earns its cost at the scale this series keeps coming back to: 50+ strategies, where some need permission checks and some don't, and that set changes over time as new approval types get added or business rules shift.

What you get from routing the check through a decorator instead of inlining it:

The permission check exists in exactly one place. If the logic for "what counts as having permission" changes - say, you add a delegation feature where a manager can temporarily grant approval rights - you change PermissionCheckingStrategyDecorator once, and every protected strategy picks up the change automatically.
Strategies stay honest about what they do. ApproveRoleChangeWorkflowAction contains only role-change logic. Reading the class tells you exactly one thing, and the [RequiresHrPermission(...)] attribute sitting above it tells you the other thing, without the two being tangled together in the method body.
Protection is opt-in and visible. Whether a strategy is gated is a one-line declaration you can see by glancing at the class - not something you have to read the entire method body to confirm.
It composes. Nothing about this design assumes there's only ever one decorator. The same mechanism - attribute declared on the strategy, applied in the factory after resolution - works for adding rate limiting, audit logging at the strategy level, or feature-flagging a strategy off entirely, each as its own decorator stacked in whatever order makes sense.

What's Left

Across three articles, a strategy now: gets resolved without a switch statement, gets permission-checked without inline if blocks, and successfully does its job - updates a record, commits a transaction, returns Result<Unit>.Success(Unit.Value).

And then what? Somewhere, someone probably needs an email. Somewhere else, every single one of these 50+ approval decisions probably needs to land in an audit trail, because "who approved what, and when" is exactly the kind of thing a system like this gets asked about during a compliance review.

If that logic goes inside the strategies, we've recreated the same mixing-of-concerns problem permission checking was just solved for. Part 4 covers the fix: publishing an event when a strategy succeeds, and letting a completely separate set of handlers react to it - including one handler that, through a neat use of class hierarchies, can catch dozens of different event types without ever being told about most of them by name.

Stop Writing Factory Switch Statements: Resolving Strategies with Attributes and Reflection

Oluwagbemileke Femi Oyeyoade — Tue, 23 Jun 2026 11:41:33 +0000

Part 2 of 4: How to pick the right strategy at runtime - without writing a second switch statement

In Part 1 of this series, we took a 50+ case switch statement and turned it into a family of small, independently testable strategy classes, each implementing IHrApprovalStrategy. The service method shrank down to almost nothing - except for one line we left as a placeholder:

// ⚠️ We still need to figure out WHICH strategy to use here.
IHrApprovalStrategy strategy = /* ??? */;

This article is about filling in that blank - and doing it in a way that doesn't quietly reintroduce the exact problem Strategy pattern was supposed to solve.

The Trap: A Factory That's Just a Switch Statement in a Trench Coat

The obvious first move is to write a factory. Given a TargetType and ActionType, it returns the right strategy:

public class HrApprovalWorkflowStrategyFactory : IHrApprovalWorkflowStrategyFactory
{
    private readonly IServiceProvider _serviceProvider;

    public HrApprovalWorkflowStrategyFactory(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public IHrApprovalStrategy Resolve(HrTargetType targetType, HrApprovalActionType actionType)
    {
        return (targetType, actionType) switch
        {
            (HrTargetType.LeaveRequest, HrApprovalActionType.Approve)
                => _serviceProvider.GetRequiredService<ApproveLeaveRequestWorkflowAction>(),
            (HrTargetType.ExpenseClaim, HrApprovalActionType.Approve)
                => _serviceProvider.GetRequiredService<ApproveExpenseClaimWorkflowAction>(),
            (HrTargetType.RoleChange, HrApprovalActionType.Approve)
                => _serviceProvider.GetRequiredService<ApproveRoleChangeWorkflowAction>(),
            (HrTargetType.Onboarding, HrApprovalActionType.Approve)
                => _serviceProvider.GetRequiredService<ApproveEmployeeOnboardingWorkflowAction>(),
            // ...46 more cases...
            _ => throw new InvalidOperationException($"No strategy for {targetType}/{actionType}")
        };
    }
}

This works. It also fails for exactly the same reasons the original switch statement failed:

Adding strategy #51 means editing this method, not just adding a file.
The factory now has compile-time knowledge of every concrete strategy type in the system.
Two developers adding two new approval types in the same sprint are, once again, editing the same method.

We didn't eliminate the central branching point - we just renamed it from ApproveRequest to Resolve and moved it one file over. If this is where the series stopped, "Strategy pattern" would really just mean "switch statement, but spread across more files," which is not a meaningfully better architecture.

The actual goal is a resolver that needs zero edits when a new strategy is added. That means the mapping from "this kind of request" to "this strategy class" can't live in a method body at all - it has to live as metadata on the strategy classes themselves, discoverable at startup.

The Fix: Let Each Strategy Declare Itself

.NET attributes are built exactly for this: attaching declarative metadata to a type, which something else can read later via reflection. Instead of a central method knowing about every strategy, each strategy class can simply announce what it's for:

[HrWorkflowStrategy(HrTargetType.LeaveRequest, HrApprovalActionType.Approve)]
public class ApproveLeaveRequestWorkflowAction : IHrApprovalStrategy
{
    // ...same implementation as Part 1, unchanged...
}

That single line replaces a case in the giant switch. No factory file needs to change. No resolver method needs to know ApproveLeaveRequestWorkflowAction exists. The class declares its own routing key and nothing else has to.

The attribute itself is a small, generic piece of infrastructure, written once and never touched again as strategies are added:

/// <summary>
/// Declares the (TargetType, ActionType, Status) combination that a strategy
/// class handles. A factory scans for this attribute at startup to build its
/// strategy registry - no manual mapping required.
/// </summary>
[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public sealed class HrWorkflowStrategyAttribute : Attribute
{
    public HrTargetType TargetType { get; }
    public HrApprovalActionType ActionType { get; }

    /// <summary>
    /// Optional. Some strategies only apply when the request is in a specific
    /// status (e.g. a "review" step before final approval). Null means the
    /// strategy applies regardless of status.
    /// </summary>
    public ApprovalRequestStatus? Status { get; }

    public HrWorkflowStrategyAttribute(HrTargetType targetType, HrApprovalActionType actionType)
    {
        TargetType = targetType;
        ActionType = actionType;
        Status = null;
    }

    public HrWorkflowStrategyAttribute(
        HrTargetType targetType,
        HrApprovalActionType actionType,
        ApprovalRequestStatus status)
    {
        TargetType = targetType;
        ActionType = actionType;
        Status = status;
    }
}

Two constructors exist because not every routing decision is just "type + action." In the real system this is modeled on, some workflows are status-dependent - a transaction-limit change, for example, needs a different strategy while it's still Pending review versus after it's been Reviewed and is awaiting final sign-off. The attribute supports an optional status without forcing every strategy to specify one. AllowMultiple = true matters too: a single strategy class is allowed to declare more than one routing key, for cases where the same logic legitimately handles two related combinations (we'll see this shortly).

The Factory: Scan Once, Resolve Many

With strategies self-describing via the attribute, the factory's job changes completely. It no longer needs to know about strategies - it just needs to scan the assembly once at startup, build a lookup table from the attributes it finds, and then do simple dictionary lookups at request time.

The top half happens exactly once, when the application boots. The bottom half - the part that runs on every single request - is nothing but a dictionary lookup. Here's the implementation:

public class HrApprovalWorkflowStrategyFactory : IHrApprovalWorkflowStrategyFactory
{
    private readonly IServiceProvider _serviceProvider;
    private readonly ILogger<HrApprovalWorkflowStrategyFactory> _logger;

    // Built once at construction time; never mutated afterward.
    private readonly IReadOnlyDictionary<
        (HrTargetType, HrApprovalActionType, ApprovalRequestStatus?), Type> _strategyCache;

    public HrApprovalWorkflowStrategyFactory(
        IServiceProvider serviceProvider,
        ILogger<HrApprovalWorkflowStrategyFactory> logger)
    {
        _serviceProvider = serviceProvider;
        _logger = logger;
        _strategyCache = DiscoverStrategies();
    }

    /// <summary>
    /// Resolves the correct strategy for the given target type, action type,
    /// and optional status. Falls back to a status-agnostic registration if no
    /// status-specific one exists.
    /// </summary>
    public IHrApprovalStrategy Resolve(
        HrTargetType targetType,
        HrApprovalActionType actionType,
        ApprovalRequestStatus? status = null)
    {
        if (!_strategyCache.TryGetValue((targetType, actionType, status), out var strategyType) &&
            !_strategyCache.TryGetValue((targetType, actionType, null), out strategyType))
        {
            _logger.LogError(
                "No strategy found for TargetType={TargetType}, ActionType={ActionType}, Status={Status}",
                targetType, actionType, status);

            throw new InvalidOperationException(
                $"No strategy found for TargetType={targetType}, ActionType={actionType}, Status={status}");
        }

        return (IHrApprovalStrategy)_serviceProvider.GetRequiredService(strategyType);
    }

    /// <summary>
    /// Scans the assembly once and caches every strategy type decorated with
    /// HrWorkflowStrategyAttribute, keyed by its routing tuple.
    /// </summary>
    private IReadOnlyDictionary<
        (HrTargetType, HrApprovalActionType, ApprovalRequestStatus?), Type> DiscoverStrategies()
    {
        var result = new Dictionary<
            (HrTargetType, HrApprovalActionType, ApprovalRequestStatus?), Type>();

        var strategies = Assembly.GetExecutingAssembly().GetTypes()
            .Where(t => typeof(IHrApprovalStrategy).IsAssignableFrom(t) && !t.IsAbstract)
            .SelectMany(t => t.GetCustomAttributes<HrWorkflowStrategyAttribute>()
                .Select(attr => new { Type = t, Attribute = attr }));

        foreach (var s in strategies)
        {
            var key = (s.Attribute.TargetType, s.Attribute.ActionType, s.Attribute.Status);

            if (!result.TryAdd(key, s.Type))
            {
                _logger.LogWarning(
                    "Duplicate strategy registration for {Key}. Keeping {Existing}, ignoring {Duplicate}",
                    key, result[key].Name, s.Type.Name);
            }
        }

        return result;
    }
}

A few details worth calling out:

The cache key is a tuple, (TargetType, ActionType, Status?). This is what lets one strategy be registered for "Approve a leave request regardless of status" while another is registered for "Review a role change only while Pending" - the same dictionary handles both shapes of rule.
The fallback lookup (status: null as a second attempt) means a strategy doesn't have to specify a status to be found. Most strategies won't care about status at all; only the few that genuinely branch on it need to say so.
Duplicate detection happens at startup, not at runtime. If two strategies accidentally claim the same routing key, you find out from a log warning when the app boots - not from a confusing bug report three weeks later when the wrong strategy silently wins.

A log warning is the minimum bar here. Throw an exception from DiscoverStrategies() instead, so the application refuses to start at all - a warning can scroll past in a sea of startup logs, a crash on boot can't. The failure mode is "one of two approval types silently gets the wrong business logic." That's worth failing fast and loud for:

  if (!result.TryAdd(key, s.Type))
  {
      throw new InvalidOperationException(
          $"Duplicate strategy registration for {key}: " +
          $"both {result[key].Name} and {s.Type.Name} claim it.");
  }

A warning keeps the app running, with one strategy silently winning the conflict. An exception turns a routing conflict into a deployment that never goes live. For something that decides which business logic runs on an approval decision, throw.

The scan runs exactly once, in the constructor, because the factory itself is registered with a long enough lifetime that this only happens at startup. There's no reflection cost on the hot path - every actual request just does a dictionary lookup.

Wiring It Up: Registering Strategies Without Naming Them

There's one more place a naive approach would force you to enumerate every strategy by name: the DI container registration. If you've used AddScoped<IHrApprovalStrategy, ApproveLeaveRequestWorkflowAction>() followed by 49 more nearly identical lines, you've recreated the same problem in your Program.cs.

Scrutor solves this with assembly scanning at the registration level too:

services.Scan(scan => scan
    .FromAssemblyOf<IHrApprovalStrategy>()
    .AddClasses(classes => classes.AssignableTo<IHrApprovalStrategy>())
    .AsSelf()                  // register by concrete type - the factory resolves by Type
    .AsImplementedInterfaces() // also register by interface, for cases that just need "a" strategy
    .WithScopedLifetime());

services.AddScoped<IHrApprovalWorkflowStrategyFactory, HrApprovalWorkflowStrategyFactory>();

One registration block, written once, covers every current and future strategy that implements IHrApprovalStrategy. Adding strategy #51 means: write the class, decorate it with [HrWorkflowStrategy(...)], done. No factory edit. No DI registration edit. No resolver method edit.

Putting It Back Together

That /* ??? */ from Part 1 now has a real answer, and the service method looks like this:

public async Task<Result<Unit>> ApproveRequest(
    string requestId,
    BaseHrApprovalDecisionRequest request,
    CancellationToken token)
{
    var authenticatedUser = await _hrSessionHelper.RetrieveAuthenticatedUser(token);

    var pendingRequest = await _context.HrApprovalRequests
        .FirstOrDefaultAsync(r => r.RequestId == requestId, token);

    if (pendingRequest == null)
    {
        return Result<Unit>.Failure("The specified request was not found.");
    }

    IHrApprovalStrategy strategy = _hrApprovalWorkflowStrategyFactory.Resolve(
        pendingRequest.TargetType, pendingRequest.ActionType, pendingRequest.Status);

    var approvalContext = new HrApprovalStrategyContext(strategy);
    return await approvalContext.Invoke(authenticatedUser, pendingRequest, request, token);
}

One line. No conditional logic, no knowledge of how many strategies exist or what any of them do. The full picture, end to end, now looks like this:

What This Buys You at 50+ Strategies

This doesn't make resolution logic disappear - it makes it declarative instead of imperative. The mapping from "type of request" to "strategy that handles it" still exists; it just lives as a one-line attribute next to the class it describes, instead of as a line buried in a giant method far away from the code it routes to.

That has a few concrete payoffs at scale:

Locality. To understand what ApproveLeaveRequestWorkflowAction handles, you read one attribute on the class itself - not a separate factory file you have to cross-reference.
No central bottleneck file. There's no single file that every new approval type must touch. The factory and the DI registration are written once, ever.
Startup-time safety. Duplicate or conflicting registrations surface when the app boots - as a log warning at minimum, or as a hard failure that stops deployment if you choose the stricter option - instead of as silent bugs discovered in production.
The pattern degrades gracefully at scale. Whether there are 10 strategies or 500, the factory's code doesn't grow by a single line.

The Next Gap

There's still something missing, and it's visible if you look closely at the real system this is based on: not every strategy should be callable by just anyone holding the right role. Approving an expense claim might be fine for any authorizer, but approving a role change to "Director" probably shouldn't be - that's a decision that might need a specific permission beyond the authorizer role generally. Right now, nothing in IHrApprovalStrategy, the factory, or the Context enforces that - permission checking would have to be written inside every strategy that needs it, which means copy-pasted authorization code scattered across 50+ classes.

That's the subject of Part 3: adding a permission check as a cross-cutting concern, wrapped around any strategy that needs it, without writing a single if (!user.HasPermission(...)) inside the strategies themselves. It's a job for the Decorator pattern.

Stop Writing Switch Statements for Approval Workflows: The Strategy Pattern in Practice

Oluwagbemileke Femi Oyeyoade — Mon, 22 Jun 2026 08:46:39 +0000

Part 1 of 4: Strategy fundamentals, illustrated with an HR approval scenario

If you've built any kind of approval workflow - leave requests, expense claims, role changes, vendor onboarding - you already know how it starts. A service method, an if statement deciding what kind of request this is, and a switch deciding what to do about it.

It works. Until it doesn't.

I built and maintain a maker-checker approval system with 50+ distinct approval workflow actions in production - different combinations of what's being approved, what action is being taken (create, approve, reject, escalate), and what state the request is currently in (pending, reviewed, escalated). Each combination can carry meaningfully different business logic, different side effects, different audit trails. For this article, I'm using an HR approval scenario - leave requests, expense claims, role changes, onboarding - as a relatable stand-in for that same shape of problem, so the ideas translate regardless of what domain you work in.

A switch statement for that is a code crime scene.

This is the story of how the Strategy pattern - one of the oldest, least flashy patterns in the GoF book - became the backbone of that system. This is Part 1 of a 4-part series:

Part 1 (this article): Strategy pattern fundamentals - replacing the switch with a Context and a family of interchangeable strategies
Part 2: Resolving the right strategy at runtime without writing a second switch statement - using attributes and reflection
Part 3: Adding cross-cutting concerns (like permission checks) to strategies without touching their business logic - the Decorator pattern
Part 4: What happens after a strategy succeeds - decoupling side effects like emails and audit logs using the Observer pattern, and a neat trick for catching dozens of event types with a single handler

Let's start where most of us start: the switch statement.

The Shape of the System This Is Based On

Two architectural details are worth laying out up front, because they explain why the data this series works with looks the way it does, rather than that just being an arbitrary choice.

First: initiating a request and reviewing/approving it are deliberately separate concerns, with separate endpoints. Creating a leave request, submitting an expense claim, requesting a role change - each of these has its own dedicated endpoint, often with its own validation and its own shape of input data, because the data needed to create a leave request looks nothing like the data needed to create a role change request. This series has nothing to say about that side of the system; it's entirely about what happens next.

Second: reviewers and authorizers don't work request-type by request-type - they work off one unified list. Whoever reviews and approves things in this system expects to see pending requests - leave requests, expense claims, role changes, onboarding, everything - in a single queue, regardless of what type each one is, rather than needing a separate screen per request type. This is intentionally a simple, three-role model - initiator, reviewer, authorizer - rather than a configurable chain of approval routes, and the unified list reflects that simplicity: there's one "pending" view per role, not a different one per request type.

That pending view isn't identical for everyone. Each reviewer or authorizer's actionable queue - the list of things they can actually approve or reject right now - only contains requests currently sitting at their stage: a reviewer's pending tab holds requests awaiting review, an authorizer's pending tab holds requests already reviewed and awaiting final sign-off. A request that moves past the review stage drops out of the reviewer's pending tab, but it doesn't vanish - the initiator and the reviewer can still look it up elsewhere, in a history or timeline view, and see exactly where it is and what's happened to it. They just can't act on it from their pending list anymore, because there's nothing left for them to do at that stage. The filtering is about what's actionable for a given role at a given moment, not about hiding the request from people who were previously involved with it.

That requirement is what actually drives the rest of this series: if leave requests and role changes lived in entirely separate tables with entirely separate shapes, there'd be no single pending list - per role - to query in the first place. Instead, every request - no matter what it's initiating - gets normalized into one shared record type once it reaches the review stage:

public class HrApprovalRequest
{
    /// <summary>Unique, externally-facing identifier for this approval request.</summary>
    public string RequestId { get; set; }

    /// <summary>The ID of the entity being acted on (a leave request ID, a role change ID, etc).</summary>
    public int EntityId { get; set; }

    /// <summary>What kind of entity this request concerns - LeaveRequest, RoleChange, Onboarding, ...</summary>
    public HrTargetType TargetType { get; set; }

    /// <summary>What action is being requested - Create, Approve, Reject, Escalate, ...</summary>
    public HrApprovalActionType ActionType { get; set; }

    public ApprovalRequestStatus Status { get; set; }

    /// <summary>Snapshot of the data before the proposed change, where applicable.</summary>
    public string? OldRequestData { get; set; }

    /// <summary>Snapshot of the proposed new data - what gets applied if this is approved.</summary>
    public string? NewRequestData { get; set; }

    /// <summary>Used for optimistic concurrency - see below.</summary>
    public byte[] RowVersion { get; set; }

    public DateTime DateCreated { get; set; }
    public DateTime? DateModified { get; set; }
    public DateTime? AuthorizedAt { get; set; }
}

A few of these columns are doing more work than they might look like at a glance:

TargetType and ActionType are exactly the two values Part 2's attribute-based factory resolves against. The whole reason that factory takes (targetType, actionType, status) as its lookup key is that this is the actual shape of the data sitting in this table - there's no richer context to resolve against than what's already on the row.
Status is what actually drives the per-viewer filtering mentioned above - it's how a query can say "show this reviewer only the requests still at the review stage" versus "show this authorizer only the ones already reviewed and awaiting final sign-off," off the same underlying table, rather than needing separate tables per stage.
OldRequestData and NewRequestData are typically JSON snapshots, deserialized inside whichever strategy handles that request type, into whatever shape that specific request type actually needs (a LeaveRequest-shaped payload, a RoleChange-shaped payload, and so on). This is part of what makes the unified queue possible - the table itself doesn't need a different schema per request type, because the type-specific shape lives inside a serialized blob, not in dedicated columns.
RowVersion matters specifically because multiple eligible reviewers can plausibly have the same request visible in their respective queues at once - eligibility isn't exclusive, it's just filtered. A RowVersion (or similar concurrency token) is what stops two authorizers from both successfully approving the same request, or one approving a request the other just rejected, by causing the second writer's SaveChangesAsync to fail with a concurrency exception instead of silently overwriting the first.

This is the table the rest of the series queries against. Every code sample from here on - the strategies in this article, the factory in Part 2, the decorator in Part 3, the events in Part 4 - exists to answer one question well: given a row in this one shared table, what should actually happen when someone approves or rejects it?

The real system this series is based on reuses the exact same strategy interface, factory, and request table for a second, separate maker-checker relationship - privileged users managing other privileged users (creating, updating, deactivating accounts with elevated access), with its own pair of roles, a Super Initiator and a Super Authorizer, distinct from the regular Initiator/Reviewer/Authorizer chain this series otherwise uses as its running example. Nothing about the strategy interface, the Context, or the factory needed to change to support that - it's handled by the same IHrApprovalStrategy family, just resolved against a different TargetType (something like AdminUser, alongside LeaveRequest, RoleChange, and the rest). That's the actual test of whether an architecture is general: it transfers to a structurally similar but otherwise unrelated problem without anyone touching the shared infrastructure.

The Problem: One Action, Many Algorithms

Picture an HR approval system - the shape of the problem translates regardless of domain. A BaseHrApprovalDecisionRequest comes in - someone clicking "Approve" or "Reject" on a pending request. The request could be:

A leave request being approved or rejected
An expense claim being approved or rejected
A role change being approved, and needing to then actually update the employee's role
An employee onboarding request being approved, which should provision accounts, notify IT, and publish an event

One layering note before the code: in this system, the controller stays thin - it does little more than authenticate the caller and forward the call. The actual ApproveRequest method, and all the logic discussed in this article, lives in a HrApprovalRequestService. That distinction matters less for the pattern itself than for where you'd actually go looking for this code in a real codebase, so I'll refer to it as the service method from here on rather than a "controller action."

Each of these needs completely different logic once approved. Visually, the naive approach forces every request through one branching decision tree before anything useful happens:

In code, that diagram becomes:

public async Task<Result<object>> ApproveRequest(
    string requestId,
    BaseHrApprovalDecisionRequest request,
    CancellationToken token)
{
    var pendingRequest = await _context.HrApprovalRequests
        .FirstOrDefaultAsync(r => r.RequestId == requestId, token);

    if (pendingRequest.TargetType == HrTargetType.LeaveRequest)
    {
        // 40 lines of leave-specific approval logic
    }
    else if (pendingRequest.TargetType == HrTargetType.ExpenseClaim)
    {
        // 35 lines of expense-specific approval logic
    }
    else if (pendingRequest.TargetType == HrTargetType.RoleChange)
    {
        // 50 lines of role-change logic, including a check on
        // whether the request is Pending vs already Reviewed
    }
    else if (pendingRequest.TargetType == HrTargetType.Onboarding)
    {
        // 60 lines of onboarding logic
    }
    // ...repeat for every target type, multiplied by every action,
    // multiplied by every status...
}

At 4 cases, this is mildly annoying. At 50+, it's unmaintainable for a few concrete reasons:

The method violates the Single Responsibility Principle - it now "owns" the business logic of every approval type in the system, not just the job of routing a request to its handler.
It violates the Open/Closed Principle - adding a new approval type means editing this method, risking regressions in unrelated branches that have nothing to do with your change.
Testing is miserable - unit testing one branch means standing up the dependencies for all branches, because they all live in one method.
Merge conflicts become routine - if two developers add two different approval types in the same sprint, they're both editing the same giant method.

This is exactly the shape of problem the Strategy pattern exists to solve: a family of algorithms, selected at runtime, that need to be interchangeable without the calling code knowing the details of each one.

The Fix: Define the Algorithm as an Interface

The first move is to recognize that "approve this leave request" and "approve this role change" are both instances of the same abstraction - "execute an approval decision" - even though their implementations are completely different.

That abstraction becomes an interface. Note that responses use the Result pattern rather than throwing exceptions for expected failure cases (request not found, already processed, validation failed) - Result<T> is a value type that explicitly carries either a success value or a structured error, forcing callers to handle both paths instead of relying on try/catch for control flow:

/// <summary>
/// Defines a contract for all HR approval workflow strategies.
/// </summary>
public interface IHrApprovalStrategy
{
    /// <summary>
    /// Executes the approval workflow logic for a given HR request.
    /// </summary>
    /// <param name="authenticatedUser">The HR admin executing the action.</param>
    /// <param name="pendingRequest">The approval request being decided on.</param>
    /// <param name="request">The raw approve/reject decision payload.</param>
    /// <param name="token">A cancellation token for cooperative cancellation.</param>
    Task<Result<Unit>> ExecuteAsync(
        HrAdminUser authenticatedUser,
        HrApprovalRequest pendingRequest,
        BaseHrApprovalDecisionRequest request,
        CancellationToken token);
}

(Unit here just stands in for "no meaningful return value, but still a Result we can inspect for success/failure" - the same role void would play if Result<T> didn't need a type argument.)

This is the entire contract. It says nothing about leave requests or expense claims - it just says "given a request and a decision, do whatever needs doing, and return a result." That's the whole point: the interface captures what all strategies have in common, not what makes them different.

Now each approval type gets its own class implementing this interface:

/// <summary>
/// Approves or rejects a pending leave request.
/// </summary>
public class ApproveLeaveRequestWorkflowAction : IHrApprovalStrategy
{
    private readonly HrContext _context;
    private readonly IEventPublisher _eventPublisher;
    private readonly ILogger<ApproveLeaveRequestWorkflowAction> _logger;

    public ApproveLeaveRequestWorkflowAction(
        HrContext context,
        IEventPublisher eventPublisher,
        ILogger<ApproveLeaveRequestWorkflowAction> logger)
    {
        _context = context ?? throw new ArgumentNullException(nameof(context));
        _eventPublisher = eventPublisher ?? throw new ArgumentNullException(nameof(eventPublisher));
        _logger = logger;
    }

    public async Task<Result<Unit>> ExecuteAsync(
        HrAdminUser authenticatedUser,
        HrApprovalRequest pendingRequest,
        BaseHrApprovalDecisionRequest request,
        CancellationToken token)
    {
        await using var transaction = await _context.Database.BeginTransactionAsync(token);

        try
        {
            if (pendingRequest.Status != ApprovalRequestStatus.Pending)
            {
                return Result<Unit>.Failure("The selected request is not pending approval.");
            }

            var leaveRequest = await _context.LeaveRequests
                .FirstOrDefaultAsync(l => l.Id == pendingRequest.EntityId, token);

            if (leaveRequest == null)
            {
                return Result<Unit>.Failure("No associated leave request found.");
            }

            var finalStatus = request.IsApproved
                ? ApprovalRequestStatus.Approved
                : ApprovalRequestStatus.Rejected;

            pendingRequest.Status = finalStatus;
            pendingRequest.AuthorizedAt = DateTime.UtcNow;
            leaveRequest.IsApproved = request.IsApproved;

            _context.HrApprovalRequests.Update(pendingRequest);
            await _context.SaveChangesAsync(token);
            await transaction.CommitAsync(token);

            await _eventPublisher.Publish(
                new LeaveRequestDecisionEvent(authenticatedUser.Id, leaveRequest.Id, request.IsApproved),
                token);

            return Result<Unit>.Success(Unit.Value);
        }
        catch (Exception ex)
        {
            _logger.LogError(ex, "Error approving leave request for {RequestId}", pendingRequest.RequestId);
            await transaction.RollbackAsync(token);
            return Result<Unit>.Failure("A system error occurred while processing the request.");
        }
    }
}

One line matters more than it looks: await _eventPublisher.Publish(new LeaveRequestDecisionEvent(...), token). The strategy doesn't send an email, doesn't write an audit log, doesn't know if anyone is even listening - it announces "this happened" and moves on. That's deliberate. Part 4 covers what happens once a strategy succeeds: side effects like notifications and audit trails are handled by a completely separate set of classes, using the Observer pattern. The strategy itself stays focused on its one job - deciding the approval outcome.

A ApproveRoleChangeWorkflowAction or ApproveEmployeeOnboardingWorkflowAction would implement the same IHrApprovalStrategy interface, but internally do completely different things - update a role and trigger a permissions sync, or provision accounts and notify IT. None of that complexity leaks into the interface, and none of it needs to live in the service method anymore.

This is the core idea of Strategy: each algorithm becomes its own class, all implementing one shared interface, so they become interchangeable from the caller's point of view. Structurally, it looks like this:

Every box on the right is a separate class, in a separate file, that can be changed, tested, and reviewed without touching any of its siblings.

The Context: Decoupling "What to Run" from "How to Run It"

Strategy pattern has one more piece that's easy to skip but worth keeping: the Context class. Its job is narrow - it holds a reference to some strategy and knows how to invoke it, without knowing or caring which concrete strategy it's holding.

public class HrApprovalStrategyContext
{
    private IHrApprovalStrategy _approvalStrategy;

    public HrApprovalStrategyContext(IHrApprovalStrategy approvalStrategy)
    {
        _approvalStrategy = approvalStrategy;
    }

    /// <summary>
    /// Swaps the strategy at runtime, if needed.
    /// </summary>
    public void SetStrategy(IHrApprovalStrategy approvalStrategy)
    {
        _approvalStrategy = approvalStrategy;
    }

    /// <summary>
    /// Executes whichever strategy is currently set.
    /// </summary>
    public async Task<Result<Unit>> Invoke(
        HrAdminUser authenticatedUser,
        HrApprovalRequest pendingRequest,
        BaseHrApprovalDecisionRequest request,
        CancellationToken token)
    {
        return await _approvalStrategy.ExecuteAsync(authenticatedUser, pendingRequest, request, token);
    }
}

It looks almost too simple to be useful - and that's exactly the point. The Context's entire job is to be boring. It's a thin wrapper that lets the calling code say "run whatever strategy you've been given" without ever writing the word if or switch.

Here's the request flow once both pieces are in place - notice the service method and the Context never reference a concrete strategy class by name:

With both pieces in place, the service method collapses down to this:

public async Task<Result<Unit>> ApproveRequest(
    string requestId,
    BaseHrApprovalDecisionRequest request,
    CancellationToken token)
{
    var authenticatedUser = await _hrSessionHelper.RetrieveAuthenticatedUser(token);

    var pendingRequest = await _context.HrApprovalRequests
        .FirstOrDefaultAsync(r => r.RequestId == requestId, token);

    if (pendingRequest == null)
    {
        return Result<Unit>.Failure("The specified request was not found.");
    }

    // ⚠️ We still need to figure out WHICH strategy to use here.
    // That's the subject of Part 2.
    IHrApprovalStrategy strategy = /* ??? */;

    var approvalContext = new HrApprovalStrategyContext(strategy);
    return await approvalContext.Invoke(authenticatedUser, pendingRequest, request, token);
}

Notice what's gone: no if, no switch, no knowledge of leave requests, role changes, or onboarding flows. The service method's job is reduced to its actual responsibility - validate the request, find the record, and hand off execution. What happens during approval is entirely delegated to whichever strategy gets plugged in. (The controller above this, as mentioned, stays just as thin as it was before - it was never the one doing this work in the first place.)

What We've Actually Gained

Strategy pattern doesn't make any individual approval handler simpler - the leave-request logic is still 40-odd lines of transaction handling, validation, and event publishing. It doesn't reduce complexity; it relocates it, from one unmanageable method into many small, independently testable, independently changeable classes.

But that relocation is the whole win:

New approval type → new class. No existing code is touched, so no existing tests can break.
Each strategy is independently unit-testable with only the dependencies it actually needs - no need to mock the entire universe of approval types to test one of them.
Each strategy can evolve on its own schedule. A bug fix in expense-claim approval can't accidentally regress role-change approval, because they no longer share a method body.
The service method becomes permanently simple, regardless of whether the system has 4 approval types or 400.

The Catch

There's an obvious gap in the code above: that /* ??? */ where the strategy gets selected. We've successfully moved the algorithms out of the service method - but something, somewhere, still has to answer the question: given this request, which of my 50+ strategy classes should I run?

If that "something" is a switch statement, we haven't actually solved the problem. We've just moved it one layer down and given it a nicer name.

That's exactly the problem Part 2 tackles: resolving the correct strategy at runtime, automatically, using attributes and reflection - so that adding strategy #51 doesn't require editing a resolver method either.

DEV Community: Oluwagbemileke Femi Oyeyoade

What Happens After Approval: Decoupling Side Effects with the Observer Pattern

The Problem: Approval Isn't Really "Done" When the Strategy Returns

The Fix: Announce What Happened, Don't Decide What Happens Next

The Event: A Plain Description of What Happened

Two Handlers, Two Very Different Subscriptions

How: The Publisher Walks Up the Inheritance Chain

Registering Both Kinds of Handler

The Full Picture

A Decision That's Easy to Miss: Where Does `Publish` Sit Relative to `Commit`?

Where This Sits Among Other Tools

Why This Was Worth Four Articles

Further Reading

Decorating Strategies: Adding Permission Checks Without Touching Business Logic

The Tempting Answer (And Why It's Wrong)

The Idea: Wrap, Don't Modify

The Part That Makes This Actually Scale: Declaring Permissions, Not Wiring Them

Tying It Together in the Factory

Why This Is Worth the Extra Layer

What's Left

Further Reading

Stop Writing Factory Switch Statements: Resolving Strategies with Attributes and Reflection

The Trap: A Factory That's Just a Switch Statement in a Trench Coat

The Fix: Let Each Strategy Declare Itself

The Factory: Scan Once, Resolve Many

Wiring It Up: Registering Strategies Without Naming Them

Putting It Back Together

What This Buys You at 50+ Strategies

The Next Gap

Further Reading

Stop Writing Switch Statements for Approval Workflows: The Strategy Pattern in Practice

The Shape of the System This Is Based On

The Problem: One Action, Many Algorithms

The Fix: Define the Algorithm as an Interface

The Context: Decoupling "What to Run" from "How to Run It"

What We've Actually Gained

The Catch

Further Reading

DEV Community: Oluwagbemileke Femi Oyeyoade

What Happens After Approval: Decoupling Side Effects with the Observer Pattern

The Problem: Approval Isn't Really "Done" When the Strategy Returns

The Fix: Announce What Happened, Don't Decide What Happens Next

The Event: A Plain Description of What Happened

Two Handlers, Two Very Different Subscriptions

How: The Publisher Walks Up the Inheritance Chain

Registering Both Kinds of Handler

The Full Picture

A Decision That's Easy to Miss: Where Does Publish Sit Relative to Commit?

Where This Sits Among Other Tools

Why This Was Worth Four Articles

Further Reading

Decorating Strategies: Adding Permission Checks Without Touching Business Logic

The Tempting Answer (And Why It's Wrong)

The Idea: Wrap, Don't Modify

The Part That Makes This Actually Scale: Declaring Permissions, Not Wiring Them

Tying It Together in the Factory

Why This Is Worth the Extra Layer

What's Left

Further Reading

Stop Writing Factory Switch Statements: Resolving Strategies with Attributes and Reflection

The Trap: A Factory That's Just a Switch Statement in a Trench Coat

The Fix: Let Each Strategy Declare Itself

The Factory: Scan Once, Resolve Many

Wiring It Up: Registering Strategies Without Naming Them

Putting It Back Together

What This Buys You at 50+ Strategies

The Next Gap

Further Reading

Stop Writing Switch Statements for Approval Workflows: The Strategy Pattern in Practice

The Shape of the System This Is Based On

The Problem: One Action, Many Algorithms

The Fix: Define the Algorithm as an Interface

The Context: Decoupling "What to Run" from "How to Run It"

What We've Actually Gained

The Catch

Further Reading

A Decision That's Easy to Miss: Where Does `Publish` Sit Relative to `Commit`?