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

소프트웨어 설계에 도메인 모델링이 중심이 되고 있습니다. 비즈니스 도메인을 중심으로 소프트웨어 개발자는 사용자의 요구를 충족시키는 풍부한 기능성을 표현하고 구현할 수 있어야 합니다. 도메인 전문가(a.k.a 현업)과 긴밀한 커뮤니케이션과 협력으로 효과적인 어플리케이션을 구축해야 합니다.

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

Manufacturing은 소프트웨어 개발에 널리 사용되는 메타포입니다. 이 메타포에 한 가지 추론할 수 있는 것은 고도로 숙련된 엔지니어는 제품을 설계하고, 덜 숙련된 노동자는 설계된 제품을 조립합니다. 많은 프로젝트는 메타포로 인해 실패하게 되었습니다. 소프트웨어 개발은 모두 디자인입니다. 모든 팀은 전문적인 역할을 가지고 있지만, 분석, 모델링, 설계 및 프로그래밍에 대한 과도한 책임 분리는 모델 주도 설계를 방해합니다.

Eric Evans, Domain-Driven Design

소프트웨어 코드의 구조와 언어(클래스명, 메소드, 변수)가 비즈니스 도메인과 일치해야 한다는 컨셉입니다. 예를 들어, 대출 신청 처리 소프트웨어를 개발한다고 할 때, 클래스에는 'LoanApplication', 'Customer'로 구성 할 수 있고, 메소드에는 'AcceptOffer'와 'Withdraw'로 작성 할 수 있습니다.

도메인 주도 설계의 핵심은 다음과 같습니다.

• 핵심 도메인 및 도메인 로직를 프로젝트의 주요 초점 설정
• 도메인 모델을 기반으로 디자인
• 기술 전문가와 도메인 전문가이 창의적 협력으로 도메인 문제를 해결하는 모델 생성

기술적으로 구현하기 위해서는 느슨한 결합(Loosly Coupling), High Cohesion

• Concept : 의미를 결정하는 단어나 문장이 나타나는 설정
• Domain : 지식의 영역(Ontology), 영향력 또는 활동. 사용자가 프로그램을 적용하는 대상 영역은 소프트웨어의 도메인
• Model : 도메인의 선택된 측면을 설명하고 해당 도메인과 관련된 문제를 해결하는데 사용할 수 있는 추상화 시스템
• Ubiquitous Language : 도메인 모델을 중심으로 구조화 되고 모든 팀 구성원이 팀의 모든 활동을 소프트웨어와 연결하는 데 사용 하는 언어

대부분의 사람들은 '설계를 고민한다는 것'이 '어떻게 생긴 것인지 고민하는 것'으로 착각한다. 설계자에게 어떤 박스를 주며 "좋아 보이게 만들어봐!" 수준으로 생각한다. 이건 우리가 생각하는 설계가 아니다. 설계는 단지 어떻게 생겼는지, 어떤 느낌인지가 아니다. 그게 어떻게 동작하는지에 대한 것이다.

Steve Jobs, Co-founder of Apple

DDD 주요 개념 요약

• 도메인: SW로 해결하고자 하는 문제의 영역, 즉 만들고자 하는 서비스를 잘게 쪼개놓은 단위
• 보편 언어(Ubiquitous language): 프로젝트에 관련된 모든 사람들이 공통으로 써야할 표현 방식. 개발을 집 짓기에 비유하면, ‘욕실’은 집주인, 설계업자, 시공업자 모두에게 욕실이어야 하고, ‘거실’은 모두가 거실로 인식해야 한다.
• Bounded Context: 프로그램 대상 영역을 덩어리로 나누는 것. 여러 도메인으로 구성된 프로젝트에서 그 도메인을 구분할 수 있게 구분해 놓은 선이다. 같은 모델이라 해도 context에 따라 해석이 달라지기도 한다. 자세한 건 아래에 서술.
• Model: 도메인의 특정 양상을 묘사한 추상화 시스템으로 도메인 관련 문제를 해결하는 데에 사용한다.
• Entity: 도메인 모델 설계 시 다른 모델과 구분할 수 있는 모델. 식별자(Id)가 존재한다.
• Value Object: Entity와 달리 고유 식별자가 없는 모델. 상수나 변하지 않는 값이 여기 해당한다.
• Aggregate: Entity의 집합으로, 생명주기가 동일한 모델을 모아놓은 root 모델이다.
• Service: 도메인간 연산을 처리하는 모델
• Repository: 모델은 저장하는 곳
• Factory: Entity나 Aggregate를 생성하는 모델

참고) 카카오헤어샵의 도메인 모델 Entity 사용 예시

@Entity
class Reservation {
  
  @Id
  long id;

  @ManyToOne
  ServiceUser serviceUser;

  @ManyToOne
  Shop shop;

  @ManyToOne
  Product product;
}

다른 예시)

Bounded Context란

프로그램 대상 영역을 덩어리로 나누는 것을 말한다. 관련한 쉬운 비유가 있다.

주택을 짓는 경우에 빗대어 생각해 볼 때, Bounded Context는 주택 전체를 구성하는 헛간, 농장, 수영장, 메인 주택 등의 큰 요소들 각각을 둘러싼 상황을 의미합니다.
특정 모델은 어떤 bounded context에 놓이는가에 따라 다르게 이해될 수 있습니다.
실제 소프트웨어를 구축함에서의 예를 들면 가령 sales를 담당하는 subdomain이 있을 수 있고, 이를 지원하는 support와 accounting 라는 subdomain 이 존재할 수 있습니다. 이러한 각각의 subdomain이 놓인 환경인 bounded context 내에서 특정 모델 customer 가 보여지는 시각은 매우 상이할 수 있습니다. sales 팀에서 고객을 보는 시각은 주로 사회적 관심사, 좋아하는 것, 욕구 등의 것일 겁니다. 하지만 accounting의 측면에서는 사용자는 그저 하나의 계정으로써 그 사람의 결제정보 만이 중요한 정보일 수 있습니다. 즉 각기 다른 bounded context에서 ubiquitous language는 비록 표현은 같지만 다른 의미를 가지게 됩니다.

DDD 장점

도메인을 정의하고 구성한다는 것은 사용자가 사용하는 영역을 정의하고 설계하는 것을 의미한다. 언뜻 DDD가 개발자에게 제약을 주는 것처럼 인식될 수 있으나, 그렇지만은 않다.
의존성이 높은 프로그램은 하나가 변경됐을 때 수정해야할 게 줄줄이 생기기 때문에 유지보수가 어렵다. 하지만 DDD에서는 도메인으로 개발 영역을 한정하고, 연결 관계(의존성)를 제어한다는 장점이 있다. UX/UI 설계를 통해 사용자가 사용할 수 있는 영역을 제한하고 제한된 영역 안에서 최적화한 경험을 설계할 수 있는 것과 마찬가지다. 사용자는 오히려 제한된 영역 안에서 더 나은 사용자 경혐을 할 수 있다.

또한 도메인(보편 언어)을 통해, 관계자 모두가 인지할 수 있는 범위 안에서 효율적으로 협업이 이루어질 수 있도록 한다. 사용자, 도메인 전문가(보통 PO, PM), 개발자가 명확하게 용어와 개발 범위를 인지함으로써 사용자를 위해 더 많은 것을 생각할 수 있는 길을 제공한다.

참고)https://naon.me/posts/til54