The Pattern-Layer Correspondence: A Practical Guide to Organizing Design Patterns

This content originally appeared on DEV Community and was authored by Gürkan

Hey dev community! Ever found yourself wondering: “Should this Factory pattern go in the Domain or Infrastructure layer?”

After years of working with layered architecture, I noticed a natural pattern in where design patterns belong. Let me introduce you to the Pattern-Layer Correspondence Principle!

The Problem: Pattern Chaos

We’ve all seen this anti-pattern:

The Aha Moment: Natural Mapping

There’s a beautiful correspondence between GoF pattern categories and software layers:

Deep Dive with C# Examples

1. Creational Patterns in Domain Layer

Why? Because object creation often involves business rules and domain knowledge.

2. Behavioral Patterns in Application Layer

Why? Because application layer coordinates behaviors and workflows.

3. Structural Patterns in Infrastructure Layer

Why? Because infrastructure handles technical implementation and integration.

Interactive: Pattern Placement Quiz

Where would you put these patterns?

1. EmailNotificationDecorator – Adds email notifications to repository operations
   • Domain
   • Application
   • Infrastructure
2. OrderProcessingWorkflow – Coordinates multiple steps in order processing
   • Domain
   • Application
   • Infrastructure
3. ProductBuilder – Constructs complex product objects with validation
   • Domain
   • Application
   • Infrastructure

Benefits of This Approach

1. Cleaner Architecture

2. Better Code Reviews

Now you can say:

“This Decorator pattern should be in Infrastructure, not Domain, because it’s structural.”

3. Easier Onboarding

New developers get a mental model:

“Need a Factory? That goes in Domain layer.”

Exceptions and Nuances

Of course, software architecture isn’t always black and white:

• Domain Events might use Observer pattern in Domain layer
• Composite pattern can be in Domain (product bundles) or Infrastructure (tree structures)
• Bridge pattern might span Application and Infrastructure

Practical Application

Refactoring Checklist:

• Move creational patterns to Domain layer
• Move behavioral patterns to Application layer
• Move structural patterns to Infrastructure layer
• Update imports and dependencies
• Verify layer boundaries are respected

New Project Template:

Let’s Discuss!

What do you think?

1. Have you seen this pattern in your projects?
2. What exceptions have you encountered?
3. Do you disagree with any of these mappings?

Share your experiences in the comments!

Follow me for more architecture insights!

This content originally appeared on DEV Community and was authored by Gürkan