Layered Architecture (N-Tier Architecture)
계층화된 아키텍처로, 각 계층이 명확한 책임을 가지고 수평으로 분리된 구조입니다.
기본 구조
일반적으로 4계층으로 구성:
┌─────────────────────┐
│ Presentation Layer │ (UI, REST API 엔드포인트)
├─────────────────────┤
│ Business Logic │ (서비스, 비즈니스 규칙)
├─────────────────────┤
│ Persistence Layer │ (데이터 접근, Repository)
├─────────────────────┤
│ Database Layer │ (실제 데이터베이스)
└─────────────────────┘
계층별 역할
| 계층 | 책임 | 예시 |
|---|---|---|
| Presentation | 사용자 입력 받기, 응답 반환 | REST Controller, GraphQL Resolver |
| Business Logic | 비즈니스 규칙 구현, 데이터 처리 | Service, Domain Logic |
| Persistence | 데이터 조회/저장 추상화 | Repository, DAO (Data Access Object) |
| Database | 실제 데이터 저장소 | MySQL, PostgreSQL, MongoDB |
특징
장점:
- 계층 간 명확한 책임 분리
- 이해하기 쉬운 구조
- 개발자가 특정 계층에만 집중 가능
- 테스트가 비교적 간단
단점:
- 간단한 기능도 모든 계층을 거쳐야 함 (과도한 abstraction)
- 수평 확장이 어려움 (한 서버에서 모든 계층이 필요)
- 한 계층의 변화가 다른 계층에 영향 (높은 결합도)
예제 (Java/Spring)
// Presentation Layer
@RestController
@RequestMapping("/users")
public class UserController {
@Autowired private UserService userService;
@PostMapping
public ResponseEntity<UserDTO> createUser(@RequestBody UserDTO dto) {
return ResponseEntity.ok(userService.save(dto));
}
}
// Business Logic Layer
@Service
public class UserService {
@Autowired private UserRepository userRepository;
public UserDTO save(UserDTO dto) {
// 비즈니스 규칙 검증
if (userRepository.existsByEmail(dto.getEmail())) {
throw new DuplicateUserException();
}
User user = new User(dto);
return userRepository.save(user).toDTO();
}
}
// Persistence Layer
@Repository
public interface UserRepository extends JpaRepository<User, Long> {
boolean existsByEmail(String email);
}언제 사용할까?
- 중소규모 애플리케이션
- 팀이 작거나 신입이 많을 때
- 빠른 개발이 필요할 때
- 명확한 책임 분리가 중요할 때