Design principles and design patterns are two essential concepts in software engineering, but they serve different purposes.

Design Principles:

Design principles are general guidelines or rules that developers should follow to create well-structured, maintainable, and scalable software systems. These principles are more abstract and provide high-level guidance on how to design software. They are often derived from best practices and lessons learned from experience. 
Here's a list of some key design principles commonly used in software engineering:

1. SOLID Principles:
   1. Single Responsibility Principle (SRP)
   2. Open/Closed Principle (OCP)
   3. Liskov Substitution Principle (LSP)
   4. Interface Segregation Principle (ISP)
   5. Dependency Inversion Principle (DIP)
2. KISS (Keep It Simple, Stupid): Favor simplicity in design and implementation.
3. DRY (Don't Repeat Yourself): Avoid code duplication and promote reusability.
4. YAGNI (You Ain't Gonna Need It): Only implement features when they are actually needed.
5. Law of Demeter (LoD) / Principle of Least Knowledge: Limit the interactions between objects, favoring loose coupling.
6. Composition Over Inheritance: Prefer composing objects over inheriting behavior to avoid deep class hierarchies and promote flexibility.
7. Separation of Concerns (SoC): Divide a system into distinct sections, each addressing a separate concern.
8. Principle of Least Astonishment (POLA): Designs should behave in ways users expect, minimizing surprises.
9. Fail Fast: Identify failures as soon as possible to reduce the cost of fixing them.
10. Don't Design by Committee: Avoid overly complex designs resulting from input from too many stakeholders.

Design Patterns:

Design patterns, on the other hand, are reusable solutions to common problems encountered during software development. They provide specific implementations of design principles and are more concrete than principles. Design patterns capture solutions to recurring design problems and encapsulate them in a structured format that can be easily reused. 

Here's a list of some common design patterns used in software engineering:

Creational Patterns:

1. Singleton Pattern: Ensures that a class has only one instance and provides a global point of access to it.
2. Factory Method Pattern: Defines an interface for creating objects but lets subclasses decide which class to instantiate.
3. Abstract Factory Pattern: Provides an interface for creating families of related or dependent objects without specifying their concrete classes.
4. Builder Pattern: Separates the construction of a complex object from its representation, allowing the same construction process to create different representations.
5. Prototype Pattern: Creates new objects by copying an existing object, avoiding the need for subclassing.

Structural Patterns:

1. Adapter Pattern: Allows incompatible interfaces to work together by providing a wrapper that converts the interface of one class into another interface that a client expects.
2. Decorator Pattern: Attaches additional responsibilities to an object dynamically, providing a flexible alternative to subclassing.
3. Proxy Pattern: Provides a placeholder for another object to control access to it.
4. Facade Pattern: Provides a simplified interface to a complex system of classes, acting as a unified interface to a set of interfaces in a subsystem.
5. Composite Pattern: Composes objects into tree structures to represent part-whole hierarchies, allowing clients to treat individual objects and compositions of objects uniformly.

Behavioral Patterns:

1. Observer Pattern: Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
2. Strategy Pattern: Defines a family of algorithms, encapsulates each one and makes them interchangeable.
3. Command Pattern: Encapsulates a request as an object, allowing for parameterization of clients with queues, requests, and operations.
4. State Pattern: Allows an object to alter its behavior when its internal state changes, encapsulating state-specific behavior into separate classes.
5. Chain of Responsibility Pattern: Passes a request along a chain of handlers, with each handler deciding either to process the request or to pass it along the chain.

Design Principle VS Design Pattern