Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems. They are not classes, packages or libraries that you can plug into your application and wait for the magic to happen. These are, rather, guidelines on how to tackle certain problems in certain situations.
Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems
Wikipedia describes them as
In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. It is a description or template for how to solve a problem that can be used in many different situations.
- Design patterns are not a silver bullet to all your problems.
- Do not try to force them; bad things are supposed to happen, if done so. Keep in mind that design patterns are solutions to problems, not solutions finding problems; so don't overthink.
- If used in a correct place in a correct manner, they can prove to be a savior; or else they can result in a horrible mess of a code.
Adaptation and extension of Design Patterns for Humans. All the explanation for design patterns (GoF) stays the same, with minor changes and additional code examples.
In software engineering, SOLID is a mnemonic acronym for five design principles intended to make object-oriented designs more understandable, flexible, and maintainable. The SOLID principles are:
- Single-responsibility principle: There should never be more than one reason for a class to change. In other words, every class should have only one responsibility.
- Open–closed principle: Software entities ... should be open for extension, but closed for modification.
- Liskov substitution principle: Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
- Interface segregation principle: Clients should not be forced to depend upon interfaces that they do not use.
- Dependency inversion principle: Depend upon abstractions, not concretions.
Domain-Driven Design is a way to design a subset of the objects in the system.
In DDD, the main goal is to establish common language with the business experts. The separation of the domain from rest of the application code is just a side effect of this main goal. It also has some say about the design of classes as entities and aggregates, but that is only within the domain itself. It has nothing to say about design outside the domain code.
Clean/Hexagonal/Onion (or CHO in short) architecture, is an architectural pattern for a system, whereas DDD is a way to design a subset of the objects in the system. The two can exist without each other, so neither is a subset of the other. If you were to use them together - then as a whole the part that is designed using DDD would be a subset of the entire system.
- Introducing Domain-Driven Design
- Modeling Problems in Software
- Elements of a Domain Model: Entities
- Elements of a Domain Model: Value Objects & Services
- Applying Aggregates and Associations
- Working with Repositories
- Adding in Domain Events and Anti-corruption Layers
- Message Queues
- Considerations
- DDD Workshop
