[PYTHON] 도메인 주도 설계(DDD) 핵심 이식 방법 3가지와 계층형 아키텍처의 차이 해결

도메인 주도 설계(Domain-Driven Design, DDD)

 

소프트웨어 개발에서 가장 어려운 것은 기술적인 문법이 아니라, 복잡하게 얽힌 비즈니스 로직을 어떻게 코드로 형상화하느냐입니다. 파이썬은 생산성이 높지만, 자칫하면 비즈니스 로직이 데이터베이스 접근 코드나 프레임워크 기능 속에 파묻히기 쉽습니다. 이러한 혼란을 해결하고 프로젝트의 지속 가능성을 확보하는 유일한 길은 도메인 주도 설계(Domain-Driven Design, DDD)를 도입하는 것입니다. 오늘은 파이썬 생태계에서 DDD를 성공적으로 이식하는 실전 방법과 기존 방식과의 결정적 차이를 심도 있게 분석해 보겠습니다.

---

1. DDD의 핵심: 유비쿼터스 언어와 바운디드 컨텍스트

DDD를 이식한다는 것은 단순히 폴더 구조를 바꾸는 것이 아닙니다. 개발자와 비즈니스 전문가가 동일한 용어를 사용하는 유비쿼터스 언어(Ubiquitous Language)를 정립하고, 특정 용어가 유효한 경계인 바운디드 컨텍스트(Bounded Context)를 설정하는 것이 첫 번째 단계입니다. 파이썬 프로젝트에서 이는 주로 모듈(Module)이나 패키지(Package) 단위로 분리되어 나타납니다. 각 컨텍스트는 독립된 도메인 모델을 가지며, 이를 통해 대규모 시스템의 복잡성을 효과적으로 해결할 수 있습니다.

---

2. 전통적 데이터 중심 설계 vs DDD 전술적 설계의 차이

우리가 흔히 사용하는 'DB 테이블 먼저 만들고 코드 짜기' 방식과 DDD 방식의 명확한 차이를 아래 표로 정리했습니다.

비교 항목	데이터 중심 설계 (Data-Driven)	도메인 주도 설계 (DDD)
중심 사고	데이터베이스 스키마 및 테이블	비즈니스 행위 및 도메인 모델
객체의 역할	데이터만 담는 바구니 (Anemic Domain Model)	데이터와 비즈니스 규칙을 함께 보유 (Rich Model)
코드의 응집도	로직이 서비스 계층에 흩어져 있음	로직이 엔티티와 밸류 객체에 응집됨
프레임워크 종속성	Django ORM 등에 강하게 결합됨	POJO(Plain Old Python Object) 지향
확장성	테이블 수정 시 전체 시스템 영향 큼	컨텍스트 경계 내에서 유연하게 수정 가능

---

3. 파이썬에 DDD를 이식하는 3가지 실전 해결 방법

해결 1: 엔티티(Entity)와 밸류 객체(Value Object)의 분리

모든 것을 데이터베이스 ID(Primary Key)로 구분하지 마세요. 속성값 자체가 의미를 가지는 밸류 객체를 적극 활용해야 합니다. 파이썬에서는 dataclasses나 Pydantic을 사용하여 불변성을 보장하는 밸류 객체를 쉽게 만들 수 있습니다.

해결 2: 리포지토리(Repository) 패턴을 통한 인프라 격리

도메인 모델은 데이터베이스가 무엇인지 몰라야 합니다. 리포지토리라는 인터페이스를 거쳐 데이터를 영속화함으로써, 나중에 DB를 PostgreSQL에서 MongoDB로 바꾸더라도 도메인 로직은 수정할 필요가 없게 해결합니다.

해결 3: 의존성 역전 원칙(DIP)의 적용

도메인 계층이 외부 인프라 계층에 의존하는 것이 아니라, 인프라 계층이 도메인 인터페이스에 의존하도록 구조를 뒤집습니다. 이는 파이썬의 추상 클래스(abc.ABC)를 통해 구현할 수 있는 가장 강력한 설계 방법입니다.

---

4. [Sample Example] 파이썬 기반 DDD 도메인 모델 구현

아래 예시는 온라인 주문 시스템에서 '주소'라는 밸류 객체와 '주문'이라는 엔티티가 어떻게 비즈니스 규칙을 내포하는지 보여주는 실전 예시입니다.

from dataclasses import dataclass
from typing import List
from uuid import UUID, uuid4

# [Value Object] 주소 정보는 그 자체로 하나의 값입니다.
@dataclass(frozen=True)
class Address:
    city: str
    street: str
    zip_code: str

# [Entity/Aggregate Root] 주문은 비즈니스 로직의 중심입니다.
class Order:
    def __init__(self, customer_id: UUID, shipping_address: Address):
        self.order_id = uuid4()
        self.customer_id = customer_id
        self.address = shipping_address
        self.status = "PENDING"
        self._items = []

    def add_item(self, product_id: UUID, price: float, quantity: int):
        # 비즈니스 규칙: 0개 이하의 상품은 담을 수 없음
        if quantity <= 0:
            raise ValueError("수량은 1개 이상이어야 합니다.")
        self._items.append({"product": product_id, "price": price, "qty": quantity})

    def calculate_total(self) -> float:
        return sum(item["price"] * item["qty"] for item in self._items)

# [Repository Interface] 도메인 계층에 위치함
class OrderRepository:
    def save(self, order: Order):
        raise NotImplementedError

---

5. DDD 이식 시 주의해야 할 2가지 함정

1. 과도한 추상화의 늪: 모든 소규모 프로젝트에 DDD를 적용할 필요는 없습니다. 단순한 CRUD 앱에 DDD를 넣는 것은 닭 잡는 데 소 잡는 칼을 쓰는 격입니다. 도메인의 복잡도가 높을 때 비로소 가치를 발휘합니다.
2. 프레임워크와의 싸움: Django와 같이 'Opinionated'한 프레임워크는 DDD의 계층 분리를 방해할 때가 있습니다. 이럴 때는 억지로 프레임워크를 뜯어고치기보다, 핵심 로직만 순수 파이썬 클래스로 분리하는 타협점이 해결책이 될 수 있습니다.

---

6. 결론: 전문가의 도구로서의 DDD

파이썬 프로젝트에 DDD를 이식하는 과정은 고통스러울 수 있지만, 그 결과물은 놀라울 정도로 견고합니다. 코드 자체가 비즈니스 문서가 되고, 테스트 코드가 명세서가 되는 경험은 개발자에게 최고의 가치를 선사합니다. 오늘 소개한 3가지 방법을 통해 복잡한 스파게티 코드를 명확한 도메인 모델로 해결해 보시길 바랍니다.

---

내용 출처 및 기술 레퍼런스

• Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
• Implementing Domain-Driven Design by Vaughn Vernon
• Architecture Patterns with Python (Cosmic Python) by Harry Percival