Clean Architecture & Design Patterns in Practice · Урок

Чистая архитектура в микросервисах

Изучите применение принципов чистой архитектуры внутри отдельных микросервисов для поддержания внутренней согласованности и автономности.

«Чистая архитектура в микросервисах» — бесплатный урок Clean Architecture & Design Patterns in Practice на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Clean Architecture & Design Patterns in Practice, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Clean Architecture & Design Patterns in Practice содержит 4 уроков всего.

Части этого урока еще не переведены и отображаются на английском.

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.

Часто задаваемые вопросы

Урок «Чистая архитектура в микросервисах» бесплатный?

Да — полный текст урока «Чистая архитектура в микросервисах» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Clean Architecture & Design Patterns in Practice, подпишись на CoddyKit PRO. Курс Clean Architecture & Design Patterns in Practice содержит 4 уроков всего.

Чему я научусь в уроке «Чистая архитектура в микросервисах»?

Изучите применение принципов чистой архитектуры внутри отдельных микросервисов для поддержания внутренней согласованности и автономности. Ты практикуешь Clean Architecture & Design Patterns in Practice с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать Clean Architecture & Design Patterns in Practice?

Предыдущий опыт не требуется. Clean Architecture & Design Patterns in Practice на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.

Сколько времени занимает урок «Чистая архитектура в микросервисах»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке Clean Architecture & Design Patterns in Practice?

Да. Каждый урок Clean Architecture & Design Patterns in Practice включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

← Назад к Clean Architecture & Design Patterns in Practice