Bounded Context란 무엇인가?

단어의 의미는 맥락에 따라 달라진다

Bound = 경계를 짓다
Bounded = 경계가 지어진
Context = 맥락
Bounded Context = 경계가 지어진 맥락

우리는 일상에서도 같은 단어를 서로 다른 의미로 사용한다.

• 배가 아프다
• 배가 떨어진다

같은 "배"라는 단어지만 의미는 전혀 다르다.

단어는 맥락(Context)에 따라 의미가 달라지고, 같은 용어가 같은 의미로 통하는 경계를 구분하는 것이 Bounded Context다.

DDD에서는 각 Bounded Context 안에서 같은 용어가 하나의 명확한 의미로 통용되는데, 이를 유비쿼터스 언어(Ubiquitous Language)라고 부른다.

Bounded Context는 어떻게 나누는가?

시스템에서 일어나는 사용자 시나리오를 나열해보면 경계가 드러난다.

이커머스 서비스를 예로 들자. 사용자가 쇼핑몰에서 물건을 사고 받기까지의 과정을 적으면 다음과 같다.

• 서비스에 진입한다
• 상품을 조회한다
• 브랜드 정보를 조회한다
• 상품을 검색한다
• 회원가입을 한다
• 상품에 좋아요를 누른다
• 상품을 장바구니에 담는다
• 상품을 주문한다
• 배송지를 입력한다
• 주문 내역을 조회한다
• 주문을 취소한다
• 배송 현황을 조회한다

이 기능들을 관련된 것끼리 묶으면 자연스럽게 경계가 생긴다.

• 상품 조회 / 검색 → Product
• 브랜드 조회 → Brand
• 좋아요 → Like
• 장바구니 → Cart
• 주문 → Order
• 배송 → Delivery
• 회원 → Member

이것이 Bounded Context 가 된다.

경계를 넘어도 상품은 상품 아닌가?

맞다. 상품이라는 단어 자체가 바뀌는 건 아니다. 달라지는 건 각 맥락에서 필요한 속성과 역할이다.

• 상품 카탈로그에서 상품은 보여주는 대상이다. 이름, 이미지, 가격, 상세정보가 중요하다.
• 장바구니에서 상품은 담아둔 대상이다. 이름, 이미지, 가격, 수량이 중요하다.
• 주문에서 상품은 구매하는 대상이다. 이름, 가격, 수량만 있으면 된다.

같은 "상품"이지만 맥락마다 관심 있는 데이터가 다르고, 수행하는 역할도 다르다. 단어의 의미 뿐만 아니라 이 역할이 달라지는 지점도 Bounded Context의 경계가 된다.

나누지 않으면 어떻게 되는가?

모든 맥락을 하나의 Product 모델에 넣으면 이렇게 된다.

public class Product {

    private Long id;
    private String name;
    private String image;
    private String description;
    private int price;

    // 상품 맥락
    private String category;
    private String brand;

    // 주문 맥락
    private String orderId;
    private String orderStatus;
    private int orderQuantity;

    // 배송 맥락
    private String deliveryStatus;
}

• 주문 로직 수정 → Product 영향
• 배송 정책 수정 → Product 영향
• 상품 정책 변경 → 전부 영향

하나를 바꾸면 전체를 테스트해야 한다.

각 맥락별로 모델을 분리하면 다음과 같다.

Product Context

public class Product {
    private Long id;
    private String name;
    private String image;
    private String description;
    private int price;
    private String category;
    private String brand;
}

Cart Context

public class CartItem {
    private Long productId;
    private String productName;
    private int price;
    private int quantity;
}

Order Context

public class OrderItem {
    private Long productId;
    private int price;
    private int quantity;
}

Delivery Context

public class Delivery {
    private Long orderId;
    private String address;
    private DeliveryStatus status;
}

배송을 수정해도 주문 모델은 영향받지 않고, 주문 정책이 바뀌어도 상품 모델은 영향받지 않는다. 각 맥락이 독립적이다.

흔한 오해

Bounded Context는 단순히 클래스 분리가 아니다.

실제 프로젝트에서는

• 팀이 분리될 수도 있고
• 데이터베이스가 분리될 수도 있고
• 심지어는 독립적인 서비스(마이크로서비스)가 될 수도 있다

클래스 분리는 단지 표현 방식 중 하나일 뿐이다.

핵심은 모델의 일관성과 책임의 경계다.

마무리

Bounded Context 나누는 이유는 변경을 격리하기 위함이다.

• 변경 영향 최소화
• 테스트 범위 축소
• 모델 복잡도 감소
• 팀 간 충돌 감소
  결국 유지보수 비용 문제다.

Bounded Context는

• 같은 단어의 의미 경계를 구분하기 위한것 뿐만 아니라
• 하나의 모델이 일관되게 유지되는 범위를 정의하기 위함이다.

그리고 그 경계를 나누는 순간, 시스템은 더 작고, 더 명확하고, 더 변경하기 쉬워진다.