[DDD 첫걸음] 1-1. 전략적 설계 - 비즈니스 도메인 분석하기.

Part 1 전략적 설계의 첫 장에서 알아볼 것.

기업이 존재하는 이유와 추구하는 목표가 무엇이며, 그 목표를 달성하기 위한 전략을 배워보자.

 

보통의 (일단 우리회사 포함) SW개발자의 경우, 코드를 작성하는게 아니라 이러한 것을 알아야하는지 의문을 가질 수 있다. 

하지만 업무에 대한 시스템을 개발하기 위해서는 해당 업무에 대한 문제에 대한 이해, 이에 앞서 그것이 존재하는 맥락을 이해할 필요가 있다.

즉, 조직의 비즈니스 전략과 소프트웨어를 만들면서 얻고자 하는 가치를 이해해야 한다.

 

비즈니스 도메인이란?

- 비즈니스 도메인은 기업의 주요 활동 영역을 정의한다.

- 일반적으로 말하자면 회사가 고객에게 제공하는 서비스를 말함

   ex) 페덱스는 배송 서비스, 스타벅스는 커피, 월마트는 소매업체

- 기업은 여러 비즈니스 도메인을 운영할 수 있다. 

  ex) 아마존은 소매와 클라우드 서비스(AWS)를 제공 / 우버는 차량 공유 서비스와 음식 배달 및 자전거 공유 서비스도 제공 

 

하위 도메인이란?

- 비즈니스 활동의 세분화된 영역.

- 하위 도메인은 전체 시스템에서 하나의 구성요소.
   따라서 각각의 하위 도메인은 목표를 달성하기 위해 서로 상호작용해야함.

 

하위 도메인 유형

• 핵심 하위 도메인 (Core subdomain)
  - 회사가 경쟁업체와 다르게 수행하고 있는 것. (경쟁 우위를 얻는 활동)
  - 구현하기 쉬운 핵심 하위 도메인은 일시적인 경쟁 우위만을 제공할 수 있음. 
     따라서 핵심 하위 도메인은 자연스럽게 복잡해짐. (경쟁력을 위해 지속적으로 발전하기때문)
  - 회사의 핵심 비즈니스는 높은 진입장벽이 있어야함. (복잡성이 높아 모방/복제가 어려워야함.)
  - 경쟁 우위를 위해 반드시 기술(알고리즘이나 기술솔루션)이 들어가야 하는 것은 아님! (ex.  보석제조업체 - 보석 디자인이 핵심)
• 일반 하위 도메인 (Generic subdomain)
  - 모든 회사가 같은 방식으로 수행하는 비즈니스 활동.
  - 핵심 하위 도메인과 유사하게 복잡성이 높고 구현하기 어렵지만, 회사에 경쟁력을 제공하지 않음.
  - 이미 검증된 솔루션으로 대체가능.
• 지원 하위 도메인 (Supporting subdomain)
  - 회사의 비즈니스를 지원하는 활동.
  - 어떠한 경쟁 우위도 제공하지 않음.
  - 지원 하위 도메인의 비즈니스 복잡성은 낮다 (간단하다.)
     ex) ETL, CRUD 인터페이스.

하위 도메인 비교

• 경쟁 우위
  - 핵심 하위 도메인만이 회사에 경쟁 우위를 제공. (경쟁사와 차별화 하기위한 회사의 전략이므로)
  - 일반 하위 도메인은 일반적인 솔루션으로 경쟁 우위 원천이 될 수 없음.
  - 지원 하위 도메인은 진입장벽이 낮고 경쟁 우위도 제공할 수 없다.
• 복잡성
  - 핵심 하위 도메인은 회사의 수익성이 좌우되기 때문에 최대한 모방하기 어려워야 한다.
  - 회사는 전략적으로 핵심 하위 도메인으로 복잡한 문제를 해결하려고함.
  - 하위 도메인 중 기꺼이 비용으로 지불할 수 있을 만큼(부업 전환)의 복잡성을 가지고 있다면 이는 핵심 하위 도메인. 
  - 지원 하위 도메인과 일반 하위 도메인을 구별할 때, 외부 솔루션을 연동하는 것보다 자체 솔루션을 구현하는 것이 더 간단하고 저렴하다면, 이것은 지원 하위 도메인이다. (지원 하위 도메인의 복잡도는 낮기 때문. 일반 하위 도메인은 복잡하지만 솔루션으로 대체가 가능함)
• 변동성
  - 핵심 하위 도메인은 자주 변경될 수 있음.
     (복잡도가 높고 기업에게 있어 경쟁력으로 작용하는 부분인 만큼 빠르게 발전, 개선, 최적화 한다.) 
  - 지원 하위 도메인은 자주 변경 되지 않음.
  - 일반 하위 도메인은 솔루션이 있음에도 패치, 버그 수정 또는 새로운 솔루션으로의 변경등 시간에 따라 변경될 수 있음.
• 솔루션 전략
  - 핵심 하위 도메인은 중요하다.
  - 그렇다고 지원 하위 도메인과 일반 하위 도메인이 중요하지 않다는 이야기는 아님.
  - 기업이 비즈니스 도메인에서 일하려면 하위 도메인 모두가 필요.
     But 각 하위 도메인의 고유한 속성을 활용하면 효율적인 전략을 선택할 수 있음.
  - 핵심 하위 도메인 : 사내에서 구현되어야 함. 
     -> 경쟁 업체들이 똑같이 할 수 없어야 하므로 솔루션 구매 혹은 외부 도입이 불가.
     -> 조직의 가장 숙련된 인재가 투입되어야한다.
     -> 따라서 솔루션을 빠르게 변경하고 발전시킬 수 있으며 짧은 시간에 우위를 갖출 수 있다.
     -> 핵심 하위 도메인은 가장 진보된 엔지니어링 기술로 구현해야 한다.
  - 일반 하위 도메인 : 이미 만들어진 제품 구입 혹은 오픈소스 솔루션을 채택해야 효율적임.
  - 지원 하위 도메인 : 지원 하위 도메인은 사내에서 구현하지 않는 것이 합리적. but 솔루션이 없다면 직접 구현 (간단하므로)
     -> 지원 하위 도메인의 구현은 간단하므로 새로운 인재를 양성할 수 있는 좋은 연습기회가 되기도 함.

하위 도메인 유형	경쟁 우위	복잡성	변동성	구현 방식	문제
핵심	예	높음	높음	사내 개발	흥미로움
일반	아니오	높음	낮음	구매/도입	해결됨
지원	아니오	낮음	낮음	사내 개발/하청	뻔함

 

하위 도메인 경계 식별

- 대다수의 소프트웨어 솔루션의 하위 도메인은 어떤식으로든 이미 존재.
- 따라서 이를 직접 분석하는 과정이 필요.

- 간단하게 회사의 부서와 기타 조직 단위로 하위 도메인을 식별/분류 해보자. 

• 하위 도메인 정제
  - 부서를 기준으로 나누었을때, 세부사항에 대해서 놓칠 수 있으므로 조금 더 깊게 파고들 필요가 있음.(정제)
  - ex) 고객 서비스 부서 -> 상담 사례 라우팅(핵심) + 헬프 데스크 시스템(일반) + 전화(일반) + 교대 관리(지원)
  
  
• 응집된 유스케이스를 하위 도메인으로
  - 기술적 관점에서 하위 도메인은 상호 연관되고 응집된 유스케이스의 집합과 유사.
  - 유스케이스 집합에서는 보통 동일한 행위자(actor), 비즈니스 엔티티(business entity)를 포함하고 모두 밀접하게 관련된 데이터의 집합을 다룸.
  - 세분화된 하위 도메인을 찾는 것을 중단하는 시점은 '응집된 유스케이스의 집합인 하위 도메인' 이 될때임. 
    (하위 도메인의 가장 정확한 경계)
  - 지원/일반 하위 도메인은 핵심 하위 도메인에 비해 정제 작업을 완화할 수 있음.
  
  
• 핵심에 집중
  - 하위 도메인은 소프트웨어 설계 의사결정을 내리는 프로세스의 어려움을 쉽게 해결하도록 돕는 도구.
  - 하위 도메인을 찾을 때, 소프트웨어와 관련되지 않은 비즈니스 기능을 식별하고 그 자체로 인정하며(핵심 하위 도메인이 소프트웨어 관련이 아닌 경우도 많다!), 작업 중인 소프트웨어 시스템과 관련된 비즈니스에 집중하는 것이 중요.

도메인 전문가(Domain expert)는 어떤 사람인가?

• 도메인 전문가는 우리가 모델링하고 코드로 구현할 비즈니스의 모든 복잡성을 알고 있는 주제 전문가.
  (즉, 소프트웨어 비즈니스 도메인에 대한 권위자)
• 시스템 분석가와 엔지니어는 비즈니스 도메인의 멘탈 모델을 소프트웨어 요구사항과 소스코드로 변환한다.
• 도메인 전문가는 요구사항을 제시하는 사람 or 소프트웨어의 최종사용자이다.
  소프트웨어는 그들의 문제를 해결해야함!