1. 도메인
1.1. 비즈니스 도메인과 하위 도메인
1.1.1. 비즈니스 도메인
•
정의
◦
회사가 제공하는 서비스
◦
기업의 주요 활동 영역을 정의
•
예)
◦
스타벅스 - 커피
◦
맥도날드 - 햄버거
◦
월마트 - 소매업체
1.1.2. 하위 도메인
•
정의
◦
비즈니스 활동의 세분화된 영역
◦
고객에게 제공하는 서비스 단위
•
종류
◦
핵심 / 일반 / 지원
•
하위 도메인들은 서로 다른 전략적 비즈니스 가치를 가짐
1.2. 하위 도메인의 종류
1.2.1. 핵심 하위 도메인 (core subdomain)
•
정의
◦
비즈니스의 차별화를 두는 핵심 영역
◦
업계에서 다른 경쟁사와 경쟁할 수 있는 능력 제공
◦
경쟁 우위의 원천
•
특징
◦
비즈니스 규칙과 로직이 집중되어 있음
◦
변화가 빈번하고 높은 수준의 유연성이 필요
◦
핵심 역량으로 여겨지며, 자체 개발이 일반적
•
예)
◦
구글
▪
비즈니스 도메인: 구글 애즈(Google Ads)
▪
핵심 하위 도메인: 순위 알고리즘
▪
검색 엔진이 제공하는 순위 알고리즘에 따라 수익성에 큰 영향을 미침
1.2.2. 일반 하위 도메인 (general subdomain)
•
정의
◦
비즈니스에 필수적이나, 핵심적이지 않은 영역
◦
일반적으로 업계 표준이나 솔루션으로 해결 가능
◦
모든 회사가 같은 방식으로 하는 일
•
특징
◦
비교적 안정적, 변화가 적음
◦
핵심 비즈니스 가치 제공 X. 운영에 필수
◦
기존 제품이나 솔루션 활용하여 구현하는 것이 효율적
•
예)
◦
사용자 인증/인가 시스템
◦
온라인 보석 판매 제조사
▪
핵심 하위 도메인: 보석 디자인
▪
일반 하위 도메인: 온라인 몰
1.2.3. 지원 하위 도메인 (supporting subdomain)
•
정의
◦
핵심 하위 도메인을 지원하는 역할
◦
핵심 기능을 구현하는데 필요한 기반 시설이나 도구를 제공
◦
회사가 경쟁자와 다르게 하고 있지만 경쟁 우위를 제공하지 않음
•
특징
◦
핵심 하위 도메인의 기능 구현 지원
◦
시스템 성능 및 안정성에 영향
◦
자체 개발 또는 외부 솔루션 활용 가능
1.2.4. 하위 도메인 정리 및 예시
•
하위 도메인 종류별 정리
구분 | 핵심 하위 도메인 | 지원 하위 도메인 | 일반 하위 도메인 |
역할 | 차별성 창출 | 핵심 기능 지원 | 비즈니스 운영 지원 |
비즈니스 로직 복잡도 | ★★★ | ★ | ★★ |
중요도 | ★★★ | ★★ | ★★ |
비즈니스 차별화 | ★★★ | ★★ | ★ |
변화 빈도 | ★★★ | ★★ | ★ |
구현 방식 | 자체 개발 | 자체 개발/외부 솔루션 활용 | 기존 제품/솔루션 활용 |
•
하위 도메인 예시
구분 | 핵심 하위 도메인 | 일반 하위 도메인 | 지원 하위 도메인 |
에듀테크 서비스 | 1) 개인 맞춤형 서비스
- AI 기반 학습 진단 및 추천
- 개인 맞춤형 학습 컨텐츠 제작 및 제공
- 실시간 학습 피드백
2) 실시간 상호작용 학습 서비스
- 온라인 강의 및 튜터링
- 실시간 토론 및 협업 학습
3) 데이터 기반 학습 분석
- 학습 데이터 수집 및 분석
- 학습 성과 평가 및 피드백
- 학습 데이터 기반 학습 모델 개발
| 1) 컨텐츠 관리
- 학습 컨텐츠 제작 도구 및 플랫폼
- 컨텐츠 저작권 관리 및 보안 시스템
- 다양한 형식의 컨텐츠
2) 사용자 관리
- 사용자 계정 생성 및 관리
- 사용자 권한 설정 및 관리
3) 결제
- 결제 수단, 결제 시스템 | 1) 시스템 인프라
- 인프라 구축
- 보안 및 백업 시스템
2) 고객 지원
- FAQ & 고객 지원 시스템
- 실시간 채팅 및 온라인 튜터링 지원
- 고객 문의 관리
3) 데이터 분석
- 데이터 분석 도구 및 플랫폼
- 시스템 사용 패턴 분석 및 개선 |
이커머스 서비스 | 1) 상품
- 상품 정보 관리, 카테고리 관리, 상품 검색, 상품 추천 등
2) 주문
- 주문 처리, 결제, 배송, 반품/환불 등
- 로켓배송
3) 고객
- 고객 정보 관리, 고객 서비스, 마케팅 등 | 1) 사용자 관리
- 사용자 계정 관리, 인증, 권한 설정 등
2) 보안
- 개인정보 보호, 데이터 보안, 시스템 보안 등
3) 결제
- 안전하고 편리한 결제 시스템 제공
4) 물류
- 효율적인 상품 배송 시스템 구축
| 1) 시스템 인프라
- 웹 서버, 데이터베이스, 네트워크 등
2) 로그 관리
- 시스템 로그 관리 및 분석
3) 모니터링
- 시스템 성능 및 안정성 모니터링 |
데이팅서비스 | 1) 매칭
- 추천하는 알고리즘 및 시스템
2) 프로필 관리
- 회원들의 프로필 정보 관리
3) 커뮤니케이션
- 채팅, 메시지 등 회원 간 소통 기능 |
1.3. 하위 도메인 변경
1.3.1. 핵심 → 일반 / 지원
•
핵심 → 일반
◦
BuyIt
▪
온라인 소매 회사
▪
배송 경로 최적화 알고리즘의 자체 주문 배송 솔루션을 가짐 (핵심 하위 도메인)
◦
DeliveryIt
▪
라는 신규 회사가 더 저렴한 작업을 처리할 수 있는 경로 최적화 서비스 제공
→ DeliveryIt 솔루션을 상용 제품으로 사용 (모든 경쟁 업체가 최적을 솔루션 사용)
◦
BuyIt의 자체 주문 배송 시스템 → 일반 하위 도메인이 됨
•
핵심 → 지원
◦
복잡성에 비해 수익성이 없는 경우
◦
다른 하위 도메인 개발을 지원하고, 최소한의 로직만 남겨둔 채 복잡성 제거
1.3.2. 지원 → 핵심 / 일반
•
지원 → 핵심
◦
비용 절감 or 추가 수익 창출 방식으로 지원 로직 최적화 하는 경우
◦
비즈니스 로직 복잡성 증가 → 수익성 개선 → 핵심 하위 도메인
◦
예) 슬랙
•
지원 → 일반
◦
지원
▪
마케팅 부서: 공급업체 계약 관리 시스템 구현 (CRUD 인터페이스)
◦
to 일반
▪
오픈 소스 계약 관리 솔루션 연동
1.3.3. 일반 → 지원
•
오픈 소스 솔루션 → 자체 시스템 개발
2. 유비쿼터스 언어
2.1. 도메인 지식과 커뮤니케이션
2.1.1. 도메인 지식
•
도메인 지식
◦
효과적인 소프트웨어 솔루션 설계를 위해 필수
•
멘탈 모델
◦
도메인 전문가가 문제를 생각하는 방식
2.1.2. 커뮤니케이션
•
효과적인 커뮤니케이션
◦
도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에 필수
•
언어 변환
◦
전통적인 소프트웨어 개발 생애주기에서는 도메인 지식이 유실되거나 변환되는 경우가 많음
◦
전통적인 소프트웨어 개발 생애주기
▪
도메인 지식 → 분석 모델
▪
분석 모델 → 요구사항
▪
요구사항 → 시스템 설계
▪
시스템 설계 → 소스코드
→ 유비쿼터스 언어 사용 필요
2.2. 유비쿼터스 언어
2.2.1. 유비쿼터스 언어
•
정의
◦
비즈니스 도메인을 설명하기 위한 단일화된 언어 체계
◦
도메인 전문가와 개발자가 공유하는 공통 언어
◦
도메인 전문가와 소프트웨어 엔지니어의 지식 간극을 단축 효과적인 도구
•
특징
◦
단순 기술 용어뿐만 아니라 비즈니스 영역의 개념, 규칙, 제약등을 담고 있음
◦
모호성, 암묵적 가정 제거 필요
◦
모든 용어는 일관성 있고 모호하지 않고 동의어가 없어야 함
◦
비즈니스 언어로, 기술 용어는 빼고 비즈니스 도메인 용어로 구성되어야 함
2.2.2. 모델링 관점의 유비쿼터스 언어
•
모델
◦
실제 시스템을 이해하는데 도움을 주는 인간의 창조물
◦
특정 목적을 달성하기 위한 자료만 제공
•
효과적인 모델링
◦
불필요한 상세 정보 삭제 & 당면한 문제를 푸는데 필요한 정보만 남김
•
비즈니스 도메인 모델링
◦
유비쿼터스 언어 발전 === 비즈니스 도메인 모델 구축
2.2.3. 유비쿼터스 언어 발전을 위한 지속적 노력
•
용어집
•
거킨 테스트(Gherkin test / Gherkin language)
◦
동사 / 행동을 포착하는데 적합
◦
예시)
▪
Scenario: 에이전트에게 새로운 지원 케이스에 대해 알린다.
•
Given: 빈센트 줄스(Vincent Jules)는 다음 내용을 담은 새로운 지원 케이스를 제출한다:
◦
나는 AWS Infinidash를 설정하는 데 도움이 필요하다.
•
When: 티켓이 울프 씨(Mr. Wolf)에게 할당된다.
•
Then: 에이전트는 새로운 티켓에 대해 알림을 받는다.
3. 바운디드 컨텍스트
3.1. 바운디드 컨텍스트
3.1.1. 바운디드 컨텍스트의 정의 및 특징
•
정의
◦
특정한 의미와 규칙을 가진 도메인 영역을 의미
◦
각 바운디드 컨텍스트는 자체적인 유비쿼터스 언어(Ubiquitous Language)와 모델을 가지고 있음
◦
명확하게 정의된 경계를 통해 다른 컨텍스트와 구분됨
•
특징
◦
명확한 경계
▪
각 바운디드 컨텍스트는 명확하게 정의된 경계를 가지고 있으며, 다른 컨텍스트와 겹치거나 모호하게 정의되어서는 안 됨
◦
자체적인 유비쿼터스 언어
▪
각 컨텍스트는 자체적인 유비쿼터스 언어를 가지고 있으며, 다른 컨텍스트와 동일한 용어라도 컨텍스트에 따라 다른 의미를 가질 수 있음
◦
자체적인 모델
▪
각 컨텍스트는 자체적인 모델을 가지고 있으며, 다른 컨텍스트의 모델과 독립적으로 작동해야 함
◦
명확한 책임
▪
각 컨텍스트는 특정한 책임을 가지고 있으며, 다른 컨텍스트의 책임과 겹치거나 모호하게 정의되어서는 안됨
3.1.2. 바운디드 컨텍스트의 경계
•
바운디드 컨텍스트 패턴
◦
물리적 경계와 소유권 경계를 규정하기 위한 도구
•
바운디드 컨텍스트의 역할
◦
물리적 경계
▪
개별 서비스 / 프로젝트로 구현되어야 함
▪
구현, 진화, 버전 관리를 독립적으로 진행
◦
소유권 경계
▪
한 팀에서만 구현, 발전, 유지 관리 해야함
▪
두 팀이 같은 바운디드 컨텍스트 작업 불가
3.1.3. 바운디드 컨텍스트 간 상호작용
•
컨트랙트
◦
바운디드 컨텍스트 사이의 접점
•
공유 커널
◦
컨텍스트 간 공통적인 기능을 추출하여 공유 커널로 정의하고, 컨텍스트 간에 공유하여 사용할 수 있음
•
변환
◦
컨텍스트 간 데이터를 변환하여 상호작용할 수 있음
•
안티커럽션 레이어
◦
컨텍스트 간 직접적인 상호작용을 피하고, 안티커럽션 레이어를 통해 간접적으로 상호작용할 수 있음
3.2. 바운디드 컨텍스트 간 관계 정의 패턴
3.2.1. 협력형 패턴 그룹
•
소통이 잘되는 팀에서 구현된 바운디드 컨텍스트
◦
단일 팀에 의해 구현된 바운디드 컨텍스트
•
파트너십 패턴
◦
바운디드 컨텍스트 간의 연동을 ad-hoc 방식으로 조정
◦
잘 구축된 협업 실무, 높은 수준의 헌신, 팀간 잦은 동기화 필수
◦
변경사항의 지속적인 통합 필요
•
공유 커널 패턴
◦
여러 바운디드 컨텍스트에서 구현되는 공유 모델
◦
소스코드의 변경이 모든 바운디드 컨텍스트에 즉시 반영되도록 구현
◦
해당 패턴 결정 기준
▪
중복 비용과 조율 비용의 비율이 가장 중요
▪
바운디드 컨텍스트간의 강한 의존관계를 만듬
▪
중복 비용 > 조율 비용 → 해당 패턴 적용
◦
단일 팀 원칙 위배 → 명분 필요
3.2.2. 사용자-제공자(customer - supplier) 패턴 그룹
•
서비스 제공자 (upstream)
•
고객 또는 사용자 (downstream)
•
연동 컨트랙트를 주도하는 권력의 불균형 존재
◦
순응주의자
◦
충돌 방지 계층
◦
오픈 호스트 서비스
•
순응주의자 패턴
◦
힘의 균형이 서비스 제공자(업스트림 팀)에 존재
◦
사용자의 선택지
▪
받아드리거나 떠나거나
•
충돌 방지 계층 패턴 (ACL: anticorruption layer)
◦
순응주의자 패턴에서 다운스트림 바운디드 컨텍스트가 이를 순응하지 않는 경우 사용
◦
충돌 방지 계층을통해 업스트림 바운디드 컨텍스트를 가공
◦
제공자의 모델을 따르는 것을 원치 않거나 순응에 필요한 노력이 가치가 없을때 사용
▪
다운 스트림 바운디드 컨텍스트가 핵심 하위 도메인을 포함하는 경우
▪
업스트림 모델이 사용자 요건에 비효율적이거나 불편한 경우
▪
제공자가 컨트랙트를 자주 변경하는 경우
•
오픈 호스트 서비스 패턴 (OHS: open-host service)
◦
힘이 사용자 측에 있는 경우 사용
◦
연동 모델(퍼블릭 인터페이스)와 구현 모델 분리
▪
구현 모델의 변경으로 부터 사용자를 보호
▪
다운스트림 바운디드 컨텍스트에 영향을 주지 않으면서 구현 자유롭게 발전 가능
◦
공표된 언어 (published language)
▪
연동 지향 언어를 통해 사용자에게 편리한 프로토콜 노출
3.2.3. 분리형 노선 (separated ways)
•
팀에 협업 의지가 없거나 협업 할 수 없을 때 사용
•
커뮤니케이션 이슈
◦
커뮤니케이션 비용이 높고 협업이 어려운 경우, 컨텍스트 기능 중복 구현
•
일반 하위 도메인
◦
일반 하위 도메인이 일반 솔루션과 연동하기 쉬운 경우 사용
◦
로깅 프레임워크