Для чего нужны слои в Spring приложении?

# Слои в Spring приложении

Определение

Слои (layers) в Spring приложении — это разделение кода на логические уровни ответственности. Классическая трёхслойная архитектура состоит из: Presentation Layer (контроллеры), Business Logic Layer (сервисы) и Data Access Layer (репозитории). Это обеспечивает чистоту, тестируемость и масштабируемость кода.

Классическая трёхслойная архитектура

┌─────────────────────────────────────┐
│  Presentation Layer (Controller)    │ HTTP запросы/ответы
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│  Business Logic Layer (Service)     │ Бизнес-логика
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│  Data Access Layer (Repository)     │ Работа с БД
└─────────────────────────────────────┘
              ↓
┌─────────────────────────────────────┐
│         Database                   │
└─────────────────────────────────────┘

Зачем нужны слои

1. Разделение ответственности (Separation of Concerns)

Каждый слой отвечает за одну задачу:

• Controller: парсинг HTTP запроса, валидация входных данных
• Service: бизнес-логика, обработка данных
• Repository: работа с базой данных

// Примерная структура
project/
├── controller/
│   └── UserController.java
├── service/
│   └── UserService.java
└── repository/
    └── UserRepository.java

2. Переиспользуемость (Reusability)

Сервис можно использовать из разных контроллеров или даже REST API и GraphQL одновременно:

// UserService — общий для обоих контроллеров
public class UserService {
    public User getUserById(Long id) { /* бизнес-логика */ }
}

@RestController
public class UserRestController {
    @GetMapping("/users/{id}")
    public User getUser(@PathVariable Long id) {
        return userService.getUserById(id);
    }
}

@Controller
public class UserWebController {
    @GetMapping("/profile/{id}")
    public String getProfile(@PathVariable Long id, Model model) {
        User user = userService.getUserById(id);
        model.addAttribute("user", user);
        return "profile";
    }
}

3. Тестируемость (Testability)

Легче писать unit-тесты, т.к. слои независимы друг от друга:

@Test
public void testUserService() {
    // Мокируем репозиторий
    UserRepository mockRepo = Mockito.mock(UserRepository.class);
    Mockito.when(mockRepo.findById(1L))
           .thenReturn(Optional.of(new User("John")));
    
    // Тестируем сервис изолированно
    UserService service = new UserService(mockRepo);
    User user = service.getUserById(1L);
    
    assertEquals("John", user.getName());
}

4. Легкость изменений (Maintainability)

Нужно изменить логику БД? Меняешь только Repository. Нужна другая стратегия кэширования? Меняешь Service. Нужен другой формат ответа? Меняешь Controller.

// Было: прямая работа с SQL
// Стало: JPA
// Контроллер и сервис не меняются!

public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByName(String name);
}

Детали каждого слоя

Controller Layer (Presentation)

Ответственность:

• Обработка HTTP запросов
• Валидация входных данных
• Преобразование ответа в JSON/HTML
• Обработка ошибок

@RestController
@RequestMapping("/api/users")
public class UserController {
    
    @Autowired
    private UserService userService;
    
    @GetMapping("/{id}")
    public ResponseEntity<User> getUserById(@PathVariable Long id) {
        try {
            User user = userService.getUserById(id);
            return ResponseEntity.ok(user);
        } catch (UserNotFoundException e) {
            return ResponseEntity.notFound().build();
        }
    }
}

Service Layer (Business Logic)

Ответственность:

• Выполнение бизнес-логики
• Валидация бизнес-правил
• Координация работы репозиториев
• Кэширование, трансакции

@Service
public class UserService {
    
    @Autowired
    private UserRepository userRepository;
    
    @Transactional
    public User saveUser(User user) {
        // Валидация бизнес-правил
        if (user.getAge() < 18) {
            throw new InvalidUserException("Must be 18+");
        }
        
        // Бизнес-логика
        user.setCreatedAt(LocalDateTime.now());
        
        // Сохранение
        return userRepository.save(user);
    }
    
    public User getUserById(Long id) {
        return userRepository.findById(id)
            .orElseThrow(() -> new UserNotFoundException("User not found"));
    }
}

Repository Layer (Data Access)

Ответственность:

• Работа с базой данных
• CRUD операции
• Query logic

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
    Optional<User> findByEmail(String email);
    List<User> findByAgeGreaterThan(int age);
    List<User> findAll(Specification<User> spec);
}

Дополнительные слои в сложных приложениях

DTO Layer (Data Transfer Objects)

Преобразование между внешним представлением и внутренним:

@Data
public class UserDTO {
    private Long id;
    private String name;
    // Не включаем чувствительные данные
}

public class UserController {
    @GetMapping("/{id}")
    public UserDTO getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return modelMapper.map(user, UserDTO.class);
    }
}

Mapper Layer

Преобразование между сущностями:

@Component
public class UserMapper {
    public UserDTO toDTO(User user) {
        return new UserDTO(user.getId(), user.getName());
    }
    
    public User toEntity(UserDTO dto) {
        return new User(dto.getName());
    }
}

Преимущества слойной архитектуры

1. Масштабируемость: легче добавлять новую функциональность
2. Параллельная разработка: разные команды работают над разными слоями
3. Быстрое тестирование: можно тестировать слои независимо
4. Легкость в поддержке: проблема локализуется в определённом слое
5. Замена реализации: например, с SQL на NoSQL

Недостатки

1. Overhead: при простых CRUD операциях может быть излишняя сложность
2. Performance: дополнительные вызовы между слоями
3. Boilerplate: много стандартного кода

Заключение

Слои в Spring приложении — это стандартный паттерн, обеспечивающий чистоту, тестируемость и удобство разработки. Даже в простых приложениях рекомендуется придерживаться этого разделения для будущей масштабируемости.