Principles and Acronyms
SOLID - Basic principles about design and programming
- Single-responsability principle: an object only has one responsability to do.
- Open-closed principle: entities must be open to be extended, closed to be modified.
- Liskov substitution principle: objects can be replaced by their subtypes without knowing it.
- Interface segregation principle: many client specific interfaces are better than a general purpose interface.
- Dependency inversion principle: it is better to depend on abstractions than implementations.
DRY - Don’t Repeat Yourself
No data should be duplicated, so changes are easier to do and everything is more clear.
KISS - Keep It Simple, Stupid
Most of the systems work better if they are kept simple, so simplicity is a key factor in system design.
Clean Code
Error
To be written
Design Patterns
Software
Software design patterns are already tested patterns that ease the process of application development.
Singleton
Singleton is a design pattern where only one instance of a class can be done per execution. After the first time, the object will return the same class already instanced. For example, a database connection is usually a singleton.
Dependency injection
Dependency injection is design pattern that provides instanced classes in an abstract way, that they can be used later in the application. Using this pattern allows the application to use external code without knowing what it requires to be executed.
A dependency injector usually has the database connection object.
Factory
Factory is a design pattern that forces you to create an abstraction of a class to homogenize its implementation and forces child classes to actually implement those methods with their own necessities. Using factories are really useful, as the application does not have to handle specific data related with 3rd party implementations, avoid repetition and decoupling of data.
An example would be: we have a Shop abstract class and, then, we have an Amazon or RedBubble Shop child classes. The Shop class forces to implement a checkout method, that then Amazon and RedBubble must implement. The application does not have to know the intricacies of how it is done, it just needs to checkout.
Façade
A Façade is a design pattern that creates interfaces that tells the developer what a class can do. It is created to be intuitive, provides a minimum context and facilitates refactoring.
This way, if we have an object that implements the Request interface, we would have a context of what that object is and which methods can possibly have implemented.
Architecture
Architecture design patterns are already tested patterns that organizes a project in application development.
MVC - Modelo Vista Controlador
El mas conocido de todos, las responsabilidades de una aplicacion se dividen en Modelo (aquello que accede a la fuente de dato), Controlador (aquello que gestiona la petición y transforma los datos) y la Vista (aquello que representa la respuesta, de aquella manera pedida por el cliente).
REST
Otro de los mas conocidos, el patron que indica que dentro de una API existen recursos y se permite su manipulacion. Esto implica que no haya una relación cliente-servidor estricta y estrecha, si no que puede que este separada. Su interfaz tiene que ser uniforme y no tiene ningun estado (cada peticion necesita toda la informacion para procesarse).
Arquitectura Hexagonal y Domain-driven Design (DDD)
El paradigma actual de desarrollo. La Arquitectura Hexagonal indica que una aplicacion tiene un core, el cual se comunica hacia el exterior a traves de adaptadores. El core contiene toda la logica de negocio, mientras que recibe todas las peticiones necesarias a traves de sus adaptadores.
El DDD diseña una aplicacion alrededor del negocio y no a traves de su funcion dentro del codigo. Asi, si una aplicacion, por ejemplo, se dedica a llegar una Liga de Magic: The Gathering, el codigo se orientaria a traves de los Torneos, Partidas o Jugadores, y sus implicaciones.
Un buen ejemplo de codigo esta en https://github.com/CodelyTV/php-ddd-example/tree/main
Un buen video resumen es este
Test-driven Design (TDD)
Este patron indica que, lo primero que se realiza, es el test y, despues, se desarrolla. Esto nos permitira entender al 100% lo que queremos desarrollar, evitar escribir mas codigo de lo normal y aumenta la resiliencia de la plataforma, implementando los tests desde un principio.
Entrevista de Diseño de Sistemas
A veces, nos pueden hacer una entrevista sobre diseño de sistemas. En estas entrevistas, preguntaran sobre como desarrollar una aplicacion desde cero. Aqui varios articulos y videos al respecto.
https://www.educative.io/blog/how-to-prepare-system-design-interview