Skip to content

Latest commit

 

History

History
93 lines (61 loc) · 4.13 KB

README.md

File metadata and controls

93 lines (61 loc) · 4.13 KB

Domain-Driven Design (DDD)

오늘은 Domain-Driven Design(DDD) 에 대해 정리하려고 한다. 소프트웨어 개발에서 DDD는 복잡한 비즈니스 로직을 코드로 풀어내는 데 초점을 맞춘 설계 방법론이다. 도메인에 대한 깊은 이해를 기반으로 소프트웨어를 설계하며, 특히 다양한 도메인을 다루는 프로젝트에서 많이 사용된다.

1. DDD란?

DDD는 비즈니스 로직을 중심으로 소프트웨어를 설계하는 방법이다. Eric Evans가 제안한 이 방법론은 비즈니스와 개발 간의 긴밀한 협업과 소통을 중요하게 여긴다.

핵심 개념

  • Domain Model: 소프트웨어에서 도메인의 핵심 개념을 코드로 표현한 것.
  • Ubiquitous Language: 비즈니스 관계자와 개발자가 같은 용어로 소통하도록 돕는 언어.

2. DDD의 주요 구성 요소

DDD를 적용할 때 사용하는 핵심 구성 요소를 살펴보자.

1) Entity

  • 고유 식별자를 가진 객체로, 상태와 동작을 캡슐화한다.
  • 예: Order, Customer.

2) Value Object

  • 식별자 없이 속성 값으로 구분되며, 불변 객체로 설계하는 경우가 많다.
  • 예: Money, Address.

3) Aggregate

  • 관련 Entity와 Value Object를 묶어 일관성을 유지하는 단위.
  • 예: Order는 여러 OrderItem 엔티티를 포함한 Aggregate로 동작한다.

4) Domain Service

  • 특정 Entity에 속하지 않는 비즈니스 로직을 처리.
  • 예: 배송 비용 계산, 결제 처리.

5) Repository

  • 데이터베이스와 상호작용을 추상화하여 Aggregate를 저장하고 조회.
  • 예: OrderRepository, CustomerRepository.

6) Factory

  • 복잡한 객체 생성을 캡슐화하여 쉽게 생성.
  • 예: 초기화된 엔티티 생성 메서드.

3. DDD의 적용 방식

DDD는 도메인과 비즈니스 로직에 대한 깊은 이해가 필수적이다. 적용 방식을 몇 가지 정리해 보았다.

1) Ubiquitous Language 도입

  • 비즈니스 관계자와 개발자가 도메인의 개념을 동일한 언어로 이해하도록 돕는다.
  • 예: 고객(Customer)과 주문(Order)의 정의를 코드에 반영.

2) Bounded Context 정의

  • 도메인을 Context로 나누어 설계하며, 각 Context는 독립적으로 작동하도록 한다.
  • 예: 주문(Order) Context와 배송(Shipping) Context를 분리.

3) Domain Model의 구현

  • Entity와 Value Object로 Domain Model을 작성하며, 복잡한 비즈니스 로직은 Domain Service로 관리.

4. DDD의 장단점

장점

  • 복잡한 로직 관리: 도메인을 중심으로 설계하므로 복잡한 로직을 쉽게 관리할 수 있다.
  • 유지보수성 향상: 코드와 비즈니스 로직 간의 간극을 줄여 변경 사항을 쉽게 반영.
  • 비즈니스와의 협업 강화: 같은 언어로 소통하므로 이해관계자 간의 협력이 원활해진다.

단점

  • 초기 비용 부담: 설계와 도메인 분석에 많은 시간과 노력이 필요하다.
  • 기술적 난이도: Aggregate, Event Sourcing 등 익숙하지 않은 개념이 포함된다.
  • 단순한 프로젝트엔 비효율적: CRUD 중심의 단순한 시스템에는 오히려 과도한 설계가 될 수 있다.

5. 주의사항

  1. 도메인의 복잡성을 제대로 이해하라

    • DDD는 복잡한 비즈니스 문제를 해결하는 데 적합하다. 단순한 프로젝트에는 다른 방법론이 더 효과적일 수 있다.

  2. Bounded Context를 명확히 정의하라

    • Context 간의 경계가 불분명하면 설계 복잡도가 증가할 수 있다.

  3. 꾸준한 피드백과 개선이 필요하다

    • 도메인은 지속적으로 변화하며, 설계 역시 변화에 맞게 개선해야 한다.

결론

DDD는 비즈니스 로직을 코드로 풀어내는 데 효과적이다. Domain 중심의 설계를 통해 복잡한 문제를 해결할 수 있지만, 적용에는 많은 준비와 학습이 필요하다. Domain과 비즈니스 요구사항에 대한 깊은 이해가 뒷받침될 때 DDD의 진가를 발휘할 수 있다.