Clean Architecture & Design Patterns in Practice · Lektion

Clean Architecture in Microservices

Erkunden Sie, wie sich die Prinzipien von Clean Architecture auf einzelne Microservices anwenden lassen, um interne Konsistenz und Eigenständigkeit zu wahren.

Clean Architecture in Microservices ist eine kostenlose Clean Architecture & Design Patterns in Practice-Lektion auf CoddyKit. Dies ist Lektion 3 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Clean Architecture & Design Patterns in Practice-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Clean Architecture & Design Patterns in Practice-Kurs umfasst insgesamt 4 Lektionen.

Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.

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.

Häufig gestellte Fragen

Ist die Lektion „Clean Architecture in Microservices“ kostenlos?

Ja — der vollständige Text von „Clean Architecture in Microservices“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Clean Architecture & Design Patterns in Practice-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Clean Architecture & Design Patterns in Practice-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „Clean Architecture in Microservices“?

Erkunden Sie, wie sich die Prinzipien von Clean Architecture auf einzelne Microservices anwenden lassen, um interne Konsistenz und Eigenständigkeit zu wahren. Du übst Clean Architecture & Design Patterns in Practice mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Clean Architecture & Design Patterns in Practice zu starten?

Keine Vorkenntnisse erforderlich. Clean Architecture & Design Patterns in Practice auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 3 von 4.

Wie lange dauert die Lektion „Clean Architecture in Microservices“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Clean Architecture & Design Patterns in Practice-Lektion Code schreiben und ausführen?

Ja. Jede Clean Architecture & Design Patterns in Practice-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

← Zurück zu Clean Architecture & Design Patterns in Practice