https://www.serch.dev/blog/2020/02/14/model-view-controller-no-es-malo-es-la-sociedad-que-lo-corrompe.html https://es.wikipedia.org/wiki/Active_record

Layered (n-tier) architecture

This approach is probably the most common because it is usually built around the database, and many applications in business naturally lend themselves to storing information in tables.

• Presentation layer (also known as UI layer)
• Application layer (also known as service layer)
• Business logic layer (also known as domain layer)
• Data access layer (also known as persistence layer)

The Model-View-Controller (MVC) structure, which is the standard software development approach offered by most of the popular web frameworks, is clearly a layered architecture

Advantage: the separation of concerns => Maintainable, Testable, Easy to assign separate "roles", Easy to update and enhance layers separately Caveats:

• Layer isolation, which is an important goal for the architecture, can also make it hard to understand the architecture without understanding every module.
• Monolithic deployment is often unavoidable, which means small changes can require a complete redeployment of the application.
• It tends to lead to monolithic applications that are hard to split up afterward.

Microservices architecture

It depends on developing small, independent modular services where each service solves a specific problem or performs a unique task and these modules communicate with each other through well-defined API to serve the business goal

Advantages:

• You can write, maintain, and deploy each microservice separately.
• A microservices architecture should be easier to scale, as you can scale only the microservices that need to be scaled.
• It’s easier to rewrite pieces of the application because they’re smaller and less coupled to other parts.

Caveats:

• The services must be largely independent.
• Not all applications have tasks that can’t be easily split into independent units.
• Performance can suffer when tasks are spread out between different microservices. The communication costs can be significant.
• Too many microservices can confuse users as parts of the web page appear much later than others.
• A single action of a user can pass through multiple microservices. There are more points of failure, and when something does go wrong, it can take more time to pinpoint the problem.

Best for:

• Websites with small components
• Development teams that are spread out, often across the globe

CQRS

CQRS is an acronym for Command and Query Responsibility Segregation. The central concept of this pattern is that an application has read operations and write operations that must be totally separated. This also means that the model used for write operations (commands) will differ from the read models (queries). Furthermore, the data will be stored in different locations. In a relational database, this means there will be tables for the command model and tables for the read model. Some implementations even store the different models in totally different databases, e.g. SQL Server for the command model and MongoDB for the read model.

This pattern is often combined with event sourcing, which we’ll cover below. When a user performs an action:

When the application needs to show data to the user:

Advantages

• Command models can focus on business logic and validation while read models can be tailored to specific scenarios.
• You can avoid complex queries (e.g. joins in SQL) which makes the reads more performant. Disadvantages
• Keeping the command and the read models in sync can become complex. Ideal for:
• Applications that expect a high amount of reads
• Applications with complex domains

Event Sourcing

This is a pattern where you don’t store the current state of your model in the database, but rather the events that happened to the model. So when the name of a customer changes, you won’t store the value in a “Name” column. You will store a “NameChanged” event with the new value (and possibly the old one too). A real-life analogy of event sourcing is accounting. When you add an expense, you don’t change the value of the total. In accounting, a new line is added with the operation to be performed. Advantages

• This software architecture pattern can provide an audit log out of the box. Each event represents a manipulation of the data at a certain point in time. Disadvantages
• It requires some discipline because you can’t just fix wrong data with a simple edit in the database.
• It’s not a trivial task to change the structure of an event. For example, if you add a property, the database still contains events without that data. Your code will need to handle this missing data graciously. Ideal for Applications That:
• Need to publish events to external systems
• Will be built with CQRS
• Have complex domains
• Need an audit log of changes to the data