Adaptación a frameworks web
Aprenda estrategias para integrar la Arquitectura Limpia con frameworks web populares (por ejemplo, Spring, ASP.NET o Django) sin acoplarla a ellos.
Adaptación a frameworks web es una lección gratuita de Clean Architecture & Design Patterns in Practice en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Clean Architecture & Design Patterns in Practice, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Clean Architecture & Design Patterns in Practice incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
Frameworks & Clean Architecture
Web frameworks like Spring, Django, or ASP.NET are powerful tools for building applications. But how do they fit into a Clean Architecture?
The challenge is to leverage their features without letting them dictate or couple to our core business logic. This lesson explores strategies to achieve that separation.
Avoiding Framework Coupling
Coupling occurs when one part of your code is highly dependent on another. In Clean Architecture, we want our inner layers (Entities, Use Cases) to be independent.
- If your Use Cases directly import Spring annotations or Django models, they are coupled.
- This makes it hard to change frameworks, test core logic, or reuse components.
The Dependency Rule Applied
Remember the Dependency Rule? Dependencies can only flow inwards. This is crucial for framework integration.
- Your core business logic (Entities, Use Cases) should never know about the web framework.
- The web framework (an outer layer) can and should depend on your core logic.
We need a bridge that respects this rule.
Presenters & Adapters Bridge
The 'Frameworks & Drivers' layer is where our web framework lives. To communicate with the inner 'Interface Adapters' layer (which contains Presenters and Controllers), we use specific patterns:
- Adapters: Translate incoming framework-specific requests into a format our Use Cases understand.
- Presenters: Format the output from Use Cases into a structure suitable for the web framework's views or JSON responses.
The Web Controller as an Adapter
In web applications, the framework's controller often serves as the primary adapter. Its job is to:
- Receive HTTP requests (e.g., from a browser or API client).
- Extract relevant data from the request.
- Convert this data into a simple object (a Request Model) that matches the Use Case's Input Port.
- Call the Use Case.
- Receive output from the Use Case (a Response Model).
- Pass this output to a Presenter to format the final HTTP response.
Defining an Input Port
Our Use Cases expose simple interfaces, called Input Ports. The web controller will depend on this interface, not the concrete Use Case implementation. This keeps the Use Case truly independent.
Here's an example of an Input Port and its corresponding Request object:
interface AddItemInputPort {
void execute(AddItemRequest request);
}
class AddItemRequest {
public final String itemName;
public final double price;
public AddItemRequest(String itemName, double price) {
this.itemName = itemName;
this.price = price;
}
}
public class Main {
public static void main(String[] args) {
// These are just definitions, not runnable logic on their own.
// We'll see them in action soon!
System.out.println("InputPort and Request defined.");
}
}Implementing a Use Case
The actual business logic resides within the Use Case. It implements the AddItemInputPort and performs the operation, completely unaware of how it was invoked (e.g., by a web request, a CLI, or a message queue).
interface AddItemInputPort {
void execute(AddItemRequest request);
}
class AddItemRequest {
public final String itemName;
public final double price;
public AddItemRequest(String itemName, double price) {
this.itemName = itemName;
this.price = price;
}
}
class AddItemUseCase implements AddItemInputPort {
@Override
public void execute(AddItemRequest request) {
System.out.println("Use Case: Processing item '" +
request.itemName + "' with price $" +
request.price + ".");
// In a real application, this would involve business rules,
// interacting with entities, and potentially repositories.
}
}
public class Main {
public static void main(String[] args) {
AddItemInputPort useCase = new AddItemUseCase();
AddItemRequest request = new AddItemRequest("Fancy Pen", 15.75);
useCase.execute(request);
}
}Web Controller Adapter in Action
Now, let's see how a simplified web controller (acting as an adapter) uses our Use Case. Notice it only interacts with the AddItemInputPort interface, not the concrete AddItemUseCase class.
interface AddItemInputPort {
void execute(AddItemRequest request);
}
class AddItemRequest {
public final String itemName;
public final double price;
public AddItemRequest(String itemName, double price) {
this.itemName = itemName;
this.price = price;
}
}
class AddItemUseCase implements AddItemInputPort {
@Override
public void execute(AddItemRequest request) {
System.out.println("Use Case processed: " + request.itemName);
}
}
// This class simulates a web framework controller
class WebFrameworkController {
private final AddItemInputPort addItemInputPort;
// Controller depends on the Input Port interface
public WebFrameworkController(AddItemInputPort addItemInputPort) {
this.addItemInputPort = addItemInputPort;
}
// This method simulates handling an HTTP POST request
public String handleHttpRequest(String name, double cost) {
System.out.println("Controller received HTTP request for: " + name);
AddItemRequest request = new AddItemRequest(name, cost);
addItemInputPort.execute(request); // Delegate to Use Case
return "HTTP Response: Item '" + name + "' added.";
}
}
public class Main {
public static void main(String[] args) {
// Setup: Inject the Use Case into the Controller
AddItemInputPort useCase = new AddItemUseCase();
WebFrameworkController controller = new WebFrameworkController(useCase);
// Simulate an incoming web request
String response = controller.handleHttpRequest("Notebook", 8.99);
System.out.println(response);
}
}Benefits of Decoupling Frameworks
This adapter-based approach offers significant advantages:
- Testability: Use Cases can be tested in isolation, without needing to boot up the entire web framework.
- Maintainability: Changes or upgrades to your web framework have minimal impact on your core business logic.
- Flexibility: You could swap out your web framework for another (e.g., from Spring to JAX-RS) with changes only in the outer 'Frameworks & Drivers' layer.
- Framework Independence: Your valuable business rules are not tied to a specific technology vendor.
Check Your Understanding
Which of the following best describes the role of a web controller when integrating a Clean Architecture application with a web framework?
Recap: Framework Integration
In this lesson, we explored how to integrate web frameworks into a Clean Architecture application while maintaining crucial separation:
- We treat the web framework as an outer layer that depends on our core logic, not the other way around.
- Controllers in the web framework act as adapters, translating web requests into Use Case Input Ports and formatting Use Case output.
- This approach ensures high testability, maintainability, and framework independence for your core application.
Aprende Clean Architecture & Design Patterns in Practice con un tutor de IA — gratis
Escribe y ejecuta código real en tu navegador, obtén ayuda instantánea de un tutor de IA disponible 24/7 y continúa donde lo dejaste en la web o en la aplicación.
- Cursos
- 12
- Lecciones
- 48
Preguntas frecuentes
¿La lección «Adaptación a frameworks web» es gratis?
Sí — el texto completo de «Adaptación a frameworks web» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Clean Architecture & Design Patterns in Practice, actualiza a CoddyKit PRO. El curso de Clean Architecture & Design Patterns in Practice incluye 4 lecciones en total.
¿Qué aprenderé en «Adaptación a frameworks web»?
Aprenda estrategias para integrar la Arquitectura Limpia con frameworks web populares (por ejemplo, Spring, ASP.NET o Django) sin acoplarla a ellos. Practicas Clean Architecture & Design Patterns in Practice con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Clean Architecture & Design Patterns in Practice?
No se requiere experiencia previa. Clean Architecture & Design Patterns in Practice en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.
¿Cuánto tiempo toma la lección «Adaptación a frameworks web»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Clean Architecture & Design Patterns in Practice?
Sí. Cada lección de Clean Architecture & Design Patterns in Practice incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Presentadores y modelos de vista
- Adaptación a frameworks web
- Pruebas de la capa de presentación
- Objetos humildes y el límite de la vista