---
category: Architecture
tags: [auto-wikified, technical-documentation, architecture]
title: Bounded Context
description: "Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)에서 유래한 용어로, 단일하고 응집력 있는 도메인 개념에 매핑되는 코드 조직의 기본 단위를 의미합니다 [1]."
last_updated: 2026-05-04
---

# Bounded Context

## 📌 Brief Summary
Bounded Context(제한된 컨텍스트)는 도메인 주도 설계(DDD)에서 유래한 용어로, 단일하고 응집력 있는 도메인 개념에 매핑되는 코드 조직의 기본 단위를 의미합니다 [1]. 이상적인 Bounded Context는 명확한 단일 책임을 지니며, 내부 로직을 독립적으로 추론할 수 있어야 합니다 [1]. 프레임워크 실전 아키텍처 패턴에서 이는 다른 모듈과의 결합도(coupling)를 최소화하여 시스템의 모듈성 및 유지보수성을 극대화하는 핵심 원리로 작용합니다 [1].

## 📖 Core Content
* **단일 책임과 독립적 패키징:** 프레임워크(예: Django)에서 Bounded Context로 기능하는 단위(App 등)는 이론적으로 별도의 패키지나 마이크로서비스로 쉽게 추출될 수 있을 만큼 독립적이어야 합니다 [1, 2]. 반면 `utils`, `helpers`, `misc`와 같이 다용도의 의미를 지닌 명명은 단일 도메인 개념을 위반하고 앱이 너무 많은 역할을 수행하고 있다는 경고 신호로 간주됩니다 [1].
* **모델 소유권과 API를 통한 캡슐화:** 각 Bounded Context는 고유한 데이터 모델을 직접 소유해야 합니다 [3]. 실전 전자상거래 백엔드 사례를 보면, 주문(`orders/`) 컨텍스트가 재고(`inventory/`)를 확인할 때 상대방의 데이터 모델을 직접 임포트하지 않고 반드시 공개된 셀렉터(Selector) API를 통해서만 상호작용하도록 데이터 접근을 격리합니다 [3].
* **마이크로서비스 경계로의 매핑:** 시스템이 성장함에 따라 잘 분리된 Bounded Context(예: NestJS의 모듈 시스템 등)는 향후 모놀리식 아키텍처를 해체할 때 자연스럽게 마이크로서비스의 경계로 확장 및 매핑될 수 있는 강력한 구조적 기반을 제공합니다 [2].

## ⚖️ Trade-offs & Caveats
* **경계 식별의 어려움과 복잡성 전가:** 시스템 내에서 Bounded Context의 경계(Boundary)를 올바르게 정의하는 것은 매우 까다로운 작업입니다 [4]. 컴포넌트를 깔끔하게 분리하지 못할 경우, 내부의 복잡성을 해소하지 못한 채 단지 컴포넌트 간의 연결(통신) 지점으로 복잡성만 전가하는 역효과를 초래할 수 있습니다 [4].
* **직접적인 모델 접근 제약과 간접성 증가:** Bounded Context 간의 독립성을 철저히 보장하기 위해 다른 도메인의 모델을 직접 참조하는 것이 금지됩니다 [3]. 모든 데이터 접근이 퍼블릭 API를 통해서만 이루어져야 하므로 [3], 시스템 내부적으로 간접 호출 계층과 인터페이스가 증가하여 설계 초기의 구현 오버헤드가 발생할 수 있습니다.

---
*Last updated: 2026-05-03*