A design pattern is a general reusable solution to a commonly occurring problem in software design.

- Stackoverflow.com Wiki
14 articles, 5 books. Go to books ↓

We can use the decorator pattern when we just want to give some added responsibility to our base class. This design pattern is a great alternative to a sub‑classing feature for extending functionality with some added advantages.

CQRS means Command Query Responsibility Segregation. Many people think that CQRS is an entire architecture, but they are wrong. CQRS is just a small pattern.

There’s a meme, originating from certain corners of the Functional side of programming, that “patterns are a language smell”. The implication being that “good” languages either already encode the patterns as language features, or they provide the tools to extend the language such that modeling the pattern explicitly isn't needed. This misses the point on rather a lot of levels.

Every developer strives to write maintainable, readable, and reusable code. Code structuring becomes more important as applications become larger. Design patterns prove crucial to solving this challenge – providing an organization structure for common issues in a particular circumstance.

Let’s imagine that GoF book doesn’t exist and forget everything related to it. Let’s start from a clean sheet.

MVVM is an evolution of MVC. It's "better" than MVC, because it reorganizes the way you layout your logic between the modules. View and Model are very clear in their purpose, so where did all the rest of the logic go ?

The idea of the observer pattern is basically to have one object, which on a change of state, updates one or more other objects on the changes. We will make this much clearer when we go through an example below.

Circuit breakers are really nice and simple pattern you can use to make your application more user and resource friendly. Especially when having some noncritical functionalities that can be disabled for few seconds and nobody might even notice.

Event sourcing is an application architecture pattern that does allow for better auditing, providing the ability of replaying the state or moving into a specific point in time and it does naturally imply a performance improvement on the write side simply because storing events in an append-only persistent store is really fast.

As the number of your services expands you're going to need to start thinking about how to organize them. Applying these two design patterns can help, provided you understand all their variations.

Despite of the differences between these patterns, some might say that Publisher-Subscriber pattern is a variation of Observer pattern because of the conceptual similarity between them. And it won’t be wrong at all. Don’t need to take the differences religiously. They are similar, aren’t they?