DDD Architecture 기초

도메인 주도 설계(Domain-Driven Design, DDD)는 소프트웨어 개발 분야에서 도메인 지향적인 개발 접근법을 의미한다. 이는 도메인의 복잡성을 관리하고 도메인 전문가와 개발자 사이의 커뮤니케이션을 촉진시키기 위한 디자인 기법들의 집합이다.

도메인 주도 설계의 핵심 아이디어는 도메인의 중심에 모델을 두고, 도메인의 언어와 개념을 사용하여 도메인을 모델링하는 것이다. 이것은 도메인 전문가와 개발자가 동일한 도메인 모델에 대해 공통의 이해를 구축하도록 돕고, 도메인의 복잡성을 완화시킨다.

도메인 주도 설계는 4가지 주요 개념으로 구성되어 있다.

1. 도메인 모델 - 도메인 개념과 관계를 설명
2. 언어 - 도메인을 정확히 표현하기 위한 용어와 문구
3. 컨텍스트 매핑 - 도메인 모델을 소프트웨어로 옮기기 위한 매핑
4. 도메인 서비스 - 도메인 객체의 행위를 캡슐화한 서비스

위의 개념들을 바탕으로 도메인 주도 설계는 복잡한 도메인을 다루기 위한 강력한 방법론을 제공한다. 개발자가 도메인에 대한 이해를 높이고, 유지보수가 쉬운 시스템을 설계할 수 있도록 돕는다.

용어 정리

• Domain
  • 문제 영역을 나타냄. 도메인 주도 설계에서는 도메인의 핵심 개념과 비즈니스 룰을 중심으로 시스템을 설계함.
• Domain Model
  • 도메인의 핵심 개념과 비즈니스 룰을 소프트웨어에서 표현한 것. 도메인 주도 설계의 핵심.
• Entity
  • 도메인에서 중요하게 다뤄지는 개념. 보통은 도메인 모델에서 속성과 행위를 가지는 클래스로 표현됨.
• Value Object
  • 엔티티의 데이터를 저장하기 위한 객체. 불변이며 식별자가 없음.
• Service
  • 엔티티의 행위를 나타내는 객체. 엔티티 간의 상호작용을 담당함.
• Repository
  • 엔티티를 저장하고, 조회하는 객체.
• Aggregation
  • 서로 관련 있는 개념을 하나의 개념으로 통합하는 것.
    
• Factory Pattern
  • 엔티티를 생성하는 표준화된 방식.
• Bounded Context
  • 도메인을 작은 맥락으로 나눈 것으로, 각 맥락은 독립적인 모델을 가지고 있다.
    
• Context Map
  • 각 Bounded Context 사이의 관계를 나타낸 것으로, 공유하는 도메인 개념과 서로 어떻게 맞물리는지를 표현한다.
    
• Ubiquitous Language
  • 도메인 전문가와 개발자 사이에서 도메인에 대한 의사소통을 위해 공통으로 사용하는 용어의 집합을 의미한다.

도메인 주도 설계의 장점

도메인 주도 설계는 다음과 같은 장점이 있다.

• 도메인에 대한 공통된 이해 구축
  • 도메인 전문가와 개발자가 도메인 모델에 대해 논의함으로써 도메인에 대한 공통된 이해를 구축할 수 있다. 이것은 변화에 대한 유연성을 높이고, 도메인의 복잡성을 관리하는 데 도움이 된다.
• 유지보수 용이
  • 도메인 언어와 개념을 사용하여 도메인 모델을 구축함으로써 시스템은 도메인 전문가에게 친숙한 언어로 표현된다. 이로 인해 도메인 전문가가 시스템을 이해하고 유지보수하는 데 용이해진다.
• 강력한 도메인 모델
  • 도메인 모델은 도메인의 핵심 개념과 비즈니스 룰을 담고 있다. 이는 애플리케이션의 핵심 로직을 구성하며, 변화에 강하고 유연한 시스템을 만들어준다.
• 설계의 질 향상
  • 도메인 주도 설계는 개발자가 도메인에 대한 이해를 높이도록 돕는다. 이는 개발자가 고품질의 설계를 하는 데 도움이 된다. 또한 개발자는 도메인의 복잡성을 최대한 완화시키기 위해 노력한다. 이는 애플리케이션의 질과 유지보수성을 높이는 데 크게 기여한다.

도메인 주도 설계의 단점

도메인 주도 설계는 많은 장점을 가지고 있지만, 다음과 같은 단점도 존재한다.

• 복잡성 증가
  • 도메인 모델을 중심으로 하는 접근법은 도메인의 복잡성을 그대로 반영한다. 이는 애플리케이션의 복잡성을 증가시킬 수 있다. 개발자는 도메인의 복잡성을 최대한 간결하게 모델링 하는 데 주의를 기울여야 한다.
• 과도한 도메인 주도
  • 모든 것을 도메인 모델로 표현하려는 과도한 도메인 주도는 설계의 유연성을 떨어뜨릴 수 있다. 때로는 도메인 외부의 요구사항을 수용하기 위해 도메인 모델을 유연하게 적용해야 하는 경우가 있다. 이러한 경우가 발생할 때 개발자는 도메인 모델을 너무 고수하지 않고, 필요에 따라 완화시킬 필요가 있다.
• 높은 학습 곡선
  • 도메인 주도 설계와 관련된 개념과 기법을 이해하고 적용하는 데는 높은 학습 곡선이 존재한다. 도메인 주도 설계는 개발자에게 상당한 책임을 요구하며, 이를 위해 도메인에 대한 깊은 이해와 경험이 필요하다. 이는 도메인 주도 설계를 적용하는 데 장애물이 될 수 있다.
• 추상화의 어려움
  • 복잡한 도메인을 모델링 할 때, 핵심 개념을 추상화하고, 적절한 수준의 추상화를 적용하는 것은 어려운 일이다. 개발자는 도메인의 복잡성을 고려하여 핵심 개념을 적절한 수준으로 추상화해야 한다. 만약 과도하게 추상화하면 이해하기 어려운 모델이 되고, 너무 낮은 수준의 추상화는 복잡성을 관리하는 데 어려움이 발생한다.
• 의존성 주입의 어려움
  • 도메인 객체 간의 의존성을 주입하는 것은 어려운 문제이다. 특히 계층 간 의존성을 주입할 때 더욱 어려움이 발생한다. 개발자는 의존성을 주입하는 방식에 신중을 기해야 하며, 이러한 방식이 도메인 모델의 의미를 훼손하지 않도록 유의해야 한다.

CQRS - 명령 및 쿼리 책임 분리

CQRS(Command and Query Responsibility Segregation)는 명령과 쿼리의 책임을 분리하는 아키텍처 스타일이다.
CQRS 패턴에서는 도메인을 변경하는 기능(Command)과 데이터를 조회하는 기능(Query)을 분리하여 개발한다.

CQRS의 장점

• 성능 향상 : 쓰기용 저장소와 읽기용 저장소를 분리하여 최적화가 가능하다. 각 저장소에 맞는 저장소를 선택할 수 있고, 읽기 전용 저장소는 읽기를 위해 최적화되어 성능을 높일 수 있다.
• 확장성 : CQRS는 독립적인 서비스로 개발되기 때문에 확장성이 뛰어나다. 각 서비스를 별도로 확장하거나 변경할 수 있다.
• 유지보수 : 각 서비스의 책임이 분명하기 때문에 유지보수가 용이하다. 명령과 쿼리를 분리하여 각 서비스의 기능이 명확해지고, 변경 사항이 한 서비스에 국한되어 유지보수가 수월해진다.
• 복잡성 감소 : 명령과 쿼리를 분리하여 복잡성을 줄일 수 있다. 각 서비스가 작은 책임을 가지기 때문에 개발과 유지보수가 간단해지고, 서로 다른 서비스 간의 의존성이 줄어들어 복잡성이 감소된다.

CQRS는 도메인 주도 설계와 잘 맞는다. 왜냐하면 CQRS는 도메인을 중심으로 개발한다는 점에서 도메인 주도 설계와 유사하고, 도메인의 복잡성을 줄이기 위해 명령과 쿼리를 분리하기 때문에 도메인 주도 설계의 단점인 복잡성을 해결하는 데 도움이 되기 때문이다.

CQRS 패턴을 적용하면 도메인 주도 설계가 가진 장점을 살리면서 단점인 복잡성을 줄일 수 있다. 따라서 CQRS는 도메인 주도 설계를 적용하는 데 있어 유용한 아키텍처 스타일이라 할 수 있다.

CQRS에서는 주로 읽기 모델(Query Model)과 쓰기 모델(Command Model)을 따로 정의한다.

• 읽기 모델 : 복잡하지 않은 데이터 구조로 읽기 최적화된 저장소에 저장된다. 도메인의 일부 측면만 포함하며, 조회 기능을 위해 설계된다.
• 쓰기 모델 : 도메인의 모든 측면을 포함한다. 도메인 논리가 복잡하게 모델링된다. 도메인을 변경하는 명령을 처리하기 위해 설계된다.
  이 두 모델은 서로 다른 데이터베이스에 저장되거나, 같은 데이터베이스의 별도 스키마를 사용할 수 있다.

CQRS 패턴은 이벤트 소싱 아키텍처와 잘 맞는다. 쓰기 모델에서 발생한 도메인 이벤트를 이벤트 버스를 통해 읽기 모델로 전달함으로써 읽기 모델을 동기화할 수 있다.
CQRS와 이벤트 소싱 아키텍처를 함께 적용하면, 읽기 모델을 지속적으로 최신 상태로 유지하면서 쓰기 모델과 읽기 모델을 완전히 분리할 수 있다.