도메인 주도 설계 첫걸음 - 1장, 2장

도메인 주도 설계 첫걸음 - part1 : 전략적 설계

 

 

01. 비즈니스 도메인 분석하기

효과적인 솔루션을 설계하고 구축하기 위해서는 그것의 바탕이 되는 구축해야 하는 SW System을 이해해야 한다.

 

 

비즈니스 도메인이란?

비즈니스 도메인 : 기업의 주요 활동 영역 정의 / 회사가 고객에게 제공하는 서비스

ex 스타벅스 : 커피, 월마트 : 소매업, 페덱스 : 배송

• 기업은 여러 비즈니스 도메인을 운영 가능
• 비즈니스 도메인은 자주 변경될 수 있음

하위 도메인이란?

하위 도메인 : 비즈니스 활동의 세분화된 영역

• 고객에게 제공하는 서비스 단위로 비즈니스 도메인 생성
• 각각의 하위 도메인은 서로 상호작용

ex) 스타벅스 : 커피 만드는 일 / 부동산(입지) / 직원 고용 / 재정 관리

비즈니스 도메인 
    ㄴ 하위 도메인 1
    ㄴ 하위 도메인 2   
    ㄴ 하위 도메인 3
    ㄴ ...

 

하위 도메인 유형

• 핵심
• 일반
• 지원

핵심 하위 도메인(core subdomain)

• 경쟁사와 다르게 수행하는 것 (ex_ 새로운 서비스 발명 / 기존 프로세스 최적화하여 차별성을 두는 것)
• 핵심 하위 도메인은 수익에 영향

Uber : 새로운 운송 수단(승차 공유 서비스) / 이후 핵심 비즈니스 최적화 및 발전(같은 방향 동승)

Google : 구글 검색 순위 알고리즘
검색 엔진 : 구글 애즈를 위한 가장 큰 플랫폼 (광고에 대한 중요 구성요소)

• 구글 애즈(Ads)의 경우 하위 도메인이 아닌 하위 도메인이 있는 별도의 비즈니스 도메인일 뿐
• 최적의 검색이 제공되지 않는다면 결국 비즈니스 수익(Ads)에 타격을 입힘

• 핵심 하위 도메인은 복잡해야 한다. (차별성)
• 핵심 하위 도메인은 반드시 기술이 들어가야하는 것은 X
• 우위는 다양한 원천에서 나올 수 있음
• 사내 내부적 구현 및 요구사항은 자주, 지속적 변경되는 것이 특징
• 유지보수가 가능하고 쉽게 개선될 수 있어야함
• 가장 진보된 엔지니어링 기술로 구현되어야 한다

핵심 하위 도메인과 핵심 도메인
에릭에반스's DDD : 핵심 하위 도메인 = 핵심 도메인
해당 저자 : 핵심 하위 도메인 선호
cause1 : 비즈니스 도메인과의 혼동을 피하기 위해
cause2 : 일반 하위 도메인이 핵심 하위 도메인으로 진화할 수 있기 때문에 더 직관적

 

일반 하위 도메인(general subdomain)

• 모든 회사가 같은 방식으로 수행하는 비즈니스 활동
• 이미 검증된 솔루션들을 이용(비용 및 신뢰성 기반 합리적) (더 이상 혁신 / 최적화가 필요 없다)
• 일반적인 솔루션이기 때문에 타사 대비 경쟁 우위에 영향을 주지 않는다.(해결된 문제들)
• 지원 하위 도메인에 비해 비교적 복잡성 높음 (암호화 알고리즘 / 인증 메커니즘)

ex) 온라인 보석 판매 제조업체

핵심 하위 : 보석 디자인
일반 하위 : 온라인 쇼핑몰

 

지원 하위 도메인(supporting subdomain)

• 회사의 비즈니스를 지원하는 활동
• 진입장벽이 낮고 어떠한 경쟁 우위를 제공하지 않음
• 이미 만들어져있는 일반적 솔루션 사용을 선호 (분명한 해결책이 있는 문제들)
• 차별적 특징 : 솔루션의 비즈니스 로직의 복잡성
• 일반적으로 지원 하위 도메인의 간단한 비즈니스 로직 : data input, ETL, CRUD 인터페이스, validation
• 정교한 디자인 패턴 및 고급 엔지니어링 기술이 필요 없음
• RAD (rapid application development) 프레임워크를 통해 우발적 복잡성 없이 로직 구현 충분
• 핵심 하위 도메인과의 비교 : 하위 도메인을 부업으로 전환할 수 있는가?, 기꺼이 비용을 지불할 수 있는가?
  • Y : 핵심  / N : 지원
• 일반 하위 도메인과의 비교 :
  • if : 외부 솔루션 대비 자체 구축이 저렴 : then 지원 / else : 일반

ex) 광고 매칭 및 효과 최적화 관련 광고 회사
창의적 카탈로그 :
- 저장 및 인덱싱하는 방식은 수익에 영향을 주지 않는다.
- 기업의 광고 관리 및 제공
- 시스템 구현에 필수적
- 따라서 콘텐츠 카탈로그 솔루션 : 지원 하위 도메인

 

 

하위 도메인 경계 식별 및 정제

• 부서 및 기타 조직 단위로의 식별 (상대적으로 광범위)
• 광범위하게 나누어진 하위 도메인에 대해 더욱 세분화하여 핵심 하위 / 지원 하위 / 일반 하위 도메인으로 구별하면 좋다.
• 세분화된 하위 도메인 분석 중단 시점 : 응집된 유스케이스의 집합인 하위 도메인 을 사용하여 판별

응집된 유스케이스를 하위 도메인으로

• 기술적 관점 : 하위 도메인은 상호 연관되고 응집된 유스케이스 집합과 유사
• 더 자세한 분석에도 설계 및 의사결정에 새로운 인사이트가 나오지 않는다면 중단
• 핵심 하위 도메인에 대해서는 가능한 많이 정제하는 것이 중요
• 지원 / 일반 하위 도메인에 대해서는 정제 작업 완화 가능
• 하위 도메인 식별시 하위 도메인이 모두 필요한지 확인

도메인 전문가

• 모델링하고 코드로 구현할 비즈니스의 모든 복잡성을 알고 있는 주제 전문가(SW 비즈니스 도메인 권위자)
• 일반적으로 도메인 전문가 : 요구사항 제시자 / SW 최종 사용자
• SW 는 그들의 문제를 해결해야 한다.

 

 

02. 도메인 지식 찾아내기

비즈니스 문제

비즈니스 도메인의 컨텍스트에서 '문제'의 의미는 광범위하다

• 비즈니스 도메인과 하위 도메인의 모든 수준에서 발생
• 하위 도메인 : 세분화된 문제 도메인(problem domain)으로 특정 비즈니스 기능에 대한 솔루션 제공 목적

도메인 지식 찾아내기

• 효과적인 SW : 멘탈 모델(도메인 전문가가 문제를 생각하는 방식)을 모방해야 한다.
• 도메인 전문가와 엔지니어간의 효과적인 지식 공유에는 효과적인 커뮤니케이션이 필요

커뮤니케이션

• 협업 : 모든 참여자가 얼마나 잘 협력할 수 있는가에 달려있음
• 프로젝트 성공 = 효과적인 커뮤니케이션 + 지식 공유 + a
• 일반적인 SW 개발 주기 : 도메인 지식 -> 분석 모델 변환
  • 중간 비즈니스 문제 해결에 중요한 도메인 지식이 손실될 수 있음
• 따라서 손실 및 왜곡이 없기 위해서는 전달 방법을 유비쿼터스 언어를 통해 전달해야한다.

유비쿼터스 언어

• 도메인 주도 설계의 초석
• 참가자들이 효과적으로 소통하기 위해 변환 보단 같은 언어에 집중(분석가, 도메인 전문가, 개발자 ...)
• 유비쿼터스 언어 = 비즈니스 언어
  • 따라서 기술 용어는 빼고 비즈니스 도메인에 관련된 용어로만 구성되어야 한다.
• 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현하는 것이 목표
  • 개발자는 비즈니스 언어로 도메인을 바라볼 수 있어야 비즈니스 로직의 운영과 이해도에 대한 능력을 발휘할 수 있다
• 반드시 정확하고 일관성 있어야 한다.
• 모호한 용어 사용을 금한다. (ex_ 정책)
• 동의어는 특정 컨텍스트 내에서 각각의 용어로 바꿔 사용한다.

비즈니스 도메인 모델

효과적인 모델링

• 모든 모델에는 목적이 존재하고, 효과적인 모델은 목적을 달성하는 데 필요한 세부사항만 포함
• 문제를 해결하는 의도와 그 목적에 필요한 정보만 제공
• 모델은 본질적으로 추상화의 결과
  • 추상화는 불필요한 상세 정보를 생략, 복잡한 문제를 다룰 수 있게 하고 당면한 문제를 푸는데 필요한 정보만 남긴다.

비즈니스 도메인 모델링

• 모델은 비즈니스가 기능을 어떻게 구현하느냐에 대한 멘탈 모델(도메인 전문가의 사고 프로세스)을 포착해야 한다.
• 모델은 SW가 해결하고자 하는 특정 문제를 해결하는 데 필요한 만큼의 비즈니스 도메인 관점을 포함해야 함

지속적인 노력

• 유비쿼터스 언어를 발전시키는 것은 언제나 진행형
  • 지속적으록 검증 및 발전시켜야 한다.

도구

유비쿼터스 언어를 수집 및 관리하는 과정의 도구와 기술

• 위키 : 유비쿼터스 언어 수집 및 관리하는 용어집으로 사용
• 위키에는 명사 뿐 아니라 행동(behavior) 를 정리하는 것이 중요
  • 행동 : 규칙, 가정, 불변성을 가진 실제 비즈니스 로직
  • 만약 행동을 정리하기 어렵다면 유스케이스 또는 거킨 테스트(Gherkin Test) 사용 추천

거킨 테스트(Gherkin Test)

• 거킨 언어로 작성된 자동화 테스트
• 도메인 전문가는 테스트를 읽고 시스템의 기대 행동 검증 가능

도전 과제

• 암묵지 : 유비쿼터스 언어를 발전시키기위해 도메인 전문가와 대화할 때 가장 중요한 지식
• 핵심 하위 도메인의 경우 비즈니스 도메인의 특성에 대해 대화를 통해 새로운 공백 및 충돌을 제대로 정의 가능
• 인내심을 가져라~~