Clean Architecture & Design Patterns in Practice · Lección

Arquitectura Limpia en microservicios

Explore cómo aplicar los principios de la Arquitectura Limpia en microservicios individuales para mantener la coherencia interna y la autonomía.

Arquitectura Limpia en microservicios es una lección gratuita de Clean Architecture & Design Patterns in Practice en CoddyKit. Esta es la lección 3 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.

Microservices Meet Clean Arch

Welcome! In this lesson, we'll explore how the powerful principles of Clean Architecture can be applied within individual microservices.

Microservices are small, independent services that communicate with each other. Combining them with Clean Architecture helps each service stay robust, maintainable, and truly autonomous.

Bounded Contexts & Microservices

A key concept in microservices is the Bounded Context. This means each service defines its own domain model and terminology, separate from others.

A microservice naturally forms a bounded context.
Clean Architecture provides a structured way to manage the internal complexity of this context.
It keeps the core business rules of the microservice isolated.

CA Inside a Microservice

Think of each microservice as having its own miniature Clean Architecture structure. The concentric circles apply internally:

Entities: Core business objects (e.g., User, Product).
Use Cases: Application-specific rules (e.g., CreateUser, PlaceOrder).
Interface Adapters: How the microservice interacts with the outside world (e.g., REST controllers, message queues) and its own data store (e.g., repositories).
Frameworks & Drivers: External tools and technologies used (e.g., Spring Boot, database drivers).

Microservice Communication Layers

For other services or clients to interact with a microservice, they typically do so through its Interface Adapters layer.

This means a microservice exposes its functionality via:

REST API endpoints (e.g., a UserController).
Message queue consumers (e.g., processing an event).
GraphQL endpoints.

These adapters translate external requests into calls to the microservice's internal Use Cases.

Data Ownership in Microservices

A fundamental principle of microservices is that each service owns its data. This means:

No shared databases between services.
The data persistence mechanism is an internal detail of the microservice.

Clean Architecture's Repository Pattern fits perfectly here, abstracting the actual database implementation from the core Use Cases.

Dependency Rule: Microservice Edition

The Dependency Rule is crucial: inner circles must not depend on outer circles. This holds true within a microservice.

Your core Entities and Use Cases should know nothing about your web framework or database.
This keeps your business logic truly independent and testable.
It allows you to swap out frameworks or databases without affecting the core.

Defining Core Contracts

Let's look at a simple example for a 'User' microservice. Here, we define the core User entity and the interfaces for our UserRepository and CreateUserUseCase.

class User {
  private String id;
  private String name;
  private String email;

  public User(String id, String name, String email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }

  public String getId() { return id; }
  public String getName() { return name; }
  public String getEmail() { return email; }
}

interface UserRepository {
  User save(User user);
  User findById(String id);
}

interface CreateUserUseCase {
  User createUser(String name, String email);
}

Implementing Core Logic

Now, we implement the CreateUserUseCase, called an Interactor. It takes a UserRepository (an outer layer interface) as a dependency, adhering to the Dependency Rule.

Run this code to see how the core logic can be tested independently!

import java.util.UUID;
import java.util.HashMap;
import java.util.Map;

class User {
  private String id;
  private String name;
  private String email;

  public User(String id, String name, String email) {
    this.id = id;
    this.name = name;
    this.email = email;
  }

  public String getId() { return id; }
  public String getName() { return name; }
  public String getEmail() { return email; }
}

interface UserRepository {
  User save(User user);
  User findById(String id);
}

interface CreateUserUseCase {
  User createUser(String name, String email);
}

class InMemoryUserRepository implements UserRepository {
  private final Map<String, User> users = new HashMap<>();

  @Override
  public User save(User user) {
    users.put(user.getId(), user);
    return user;
  }

  @Override
  public User findById(String id) {
    return users.get(id);
  }
}

class CreateUserInteractor implements CreateUserUseCase {
  private final UserRepository userRepository;

  public CreateUserInteractor(UserRepository userRepository) {
    this.userRepository = userRepository;
  }

  @Override
  public User createUser(String name, String email) {
    String id = UUID.randomUUID().toString();
    User newUser = new User(id, name, email);
    return userRepository.save(newUser);
  }
}

public class Main {
  public static void main(String[] args) {
    // This simulates the wiring and interaction in a microservice
    UserRepository repo = new InMemoryUserRepository();
    CreateUserUseCase useCase = new CreateUserInteractor(repo);

    User user1 = useCase.createUser("Alice", "alice@example.com");
    System.out.println("Created User: " + user1.getName());

    User foundUser = repo.findById(user1.getId());
    System.out.println("Found User Email: " + foundUser.getEmail());
  }
}

The API Adapter Role

In a real microservice, a UserController (part of the Interface Adapters layer) would receive an HTTP request, map it to a DTO, call the CreateUserUseCase, and then return an HTTP response.

This controller depends on the Use Case, but the Use Case doesn't depend on the controller.

Why This Approach Works

Applying Clean Architecture to microservices offers significant benefits:

High Cohesion: Each microservice's core logic is tightly focused.
Loose Coupling: Core logic is decoupled from frameworks, databases, and even other services.
Independent Deployment: Changes to the UI or database don't affect core business rules.
Enhanced Testability: Business logic can be unit-tested without needing a database or web server.
Maintainability: Easier to understand, modify, and extend over time.

Check Your Understanding

Why is applying Clean Architecture principles within individual microservices particularly beneficial?

Microservices & CA: Summary

In this lesson, we've seen how Clean Architecture provides a robust internal structure for individual microservices. By adhering to the Dependency Rule and separating concerns into layers, each microservice becomes:

Highly autonomous
Easily testable
Flexible and maintainable

This combination ensures that your microservice ecosystem remains agile and resilient.

Preguntas frecuentes

¿La lección «Arquitectura Limpia en microservicios» es gratis?

Sí — el texto completo de «Arquitectura Limpia en microservicios» 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 «Arquitectura Limpia en microservicios»?

Explore cómo aplicar los principios de la Arquitectura Limpia en microservicios individuales para mantener la coherencia interna y la autonomía. 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 3 de 4.

¿Cuánto tiempo toma la lección «Arquitectura Limpia en microservicios»?

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

← Volver a Clean Architecture & Design Patterns in Practice