Software design patterns

A personal opinion on design patterns.

When to use them?

Most code base follow design patterns, even those that are considered to have a high degreed of technical debt. Design patterns are used to solve recurring problems in the business domain. Often time, they are present in the programming languages of choice, for example (c#): extensions methods, Linq, IoC, etc.

1. Favor design patterns to encapsulate discreet domain business functions that describe the business problems (Clean-Architecture, the architecture scream the domain problem).
2. For recurring cross-cutting concerns.
3. To decouple business function implementations from external agencies.
4. Setting business functions boundaries.
5. Simplify code base aligned to business function evolution.
6. Address technical debt and/or implementations that deviate from domain problems.

Use design patterns to simplify the business domain, avoid accidental complexity.

When to refactor?

Refactoring is an ongoing work in progress. Business evolve, so the source code too. Refactor to patterns following the above guidelines.