도메인 주도 설계 첫걸음 Part 1. 전략적 설계

도메인 주도 설계 방법(Domain-Driven Design; DDD)은 크게 전략적 설계와 전술적 설계 두가지로 나눌 수 있다. 

1. 전략적 설계 - What? Why? 어떤 소프트웨어를, 왜 만드는지
2. 전술적 설계 - How? 소프트웨어 각각의 구성요소가 구현되는 방법

먼저 전략적 설계 관점에서 도메인 주도 설계의 패턴과 원칙을 탐색해보자. 

1장 비즈니스 도메인 분석하기

비즈니스 도메인

• 기업의 주요 활동 영역으로, 일반적으로 회사가 고객에게 제공하는 서비스
• ex) 아마존 - 소매업 & 클라우드 서비스

하위 도메인

비즈니스 도메인의 목표를 달성하기 위해 세분화된 영역으로 하위 도메인끼리 상호작용을 해야 함

• 핵심 하위도메인
  • 경쟁업체와 차별화된 서비스로 새로운 제품이나 기존 프로세스를 최적화하여 비용을 줄이는 것
  • 회사의 수익성이 좌우되기 때문에 경쟁업체가 최대한 모방하기 어렵고 복잡한 문제를 해결해야 함
  • 요구사항이 자주 지속적으료 변경될 것이므로 솔루션은 유지보수가 가능하고쉽게 개선될 수 있어야함
• 일반 하위 도메인
  • 모든 회사가 같은 방식으로 수행하는 비즈니스 활동
  • 복잡하지만 이미 많은 사람들이 고민하고 해결하기 위해 시간을 투자했기 때문에 맞춤형 솔루션이 어느정도 나와있고 이로인해 경쟁력이 없음
  • 제품을 구입하나 오픈소스 솔루션을 채택하는 것이 효율적
• 지원 하위 도메인
  • 회사의 비즈니스를 지원하는 활동으로 경쟁 우위 없고 이미 만들어진 솔루션을 활용
  • 기본적인 ETL작업과 CRUD 인터페이스를 가진 명확한 비즈니스 로직

2장 도메인 지식 찾아내기

• 효과적인 소프트웨어 솔루션을 설계하려면 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야 함
• 전통적인 소프트웨어 개발 생애주기
  • 도메인 지식 > 분석모델 > 요구사항 > 시스템 설계 > 소스코드
• 이 같은 과정에서는 도메인 지식이 종종 왜곡된 상태로 소프트웨어 엔지니어에게 전달되어 잘못된 솔루션을 구현하게 됨

유비쿼터스 언어

• 효과적 소통을 위해 변환에 의존하지 말고 같은 언어를 사용하여 도메인 전문가와 소프트웨어 엔지니어 사이의 간극을 메워야 함
• 기술용어를 빼고 비즈니스 도메인에 관련된 용어로만 구성하여 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해 할 수 있는 관점으로 표현

예시)
기술언어
  - 광고의 아이프레임(iframe)은 HTML 파일을 표시한다.
  - 캠페인은 ‘활성-할당(active-placement)’ 테이블에 하나의 연관 레코드가 있어야 게시된다.
비즈니스 언어
  - 광고 캠페인은다양한 창의적인 자료를 전시할 수있다.
  - 캠페인은 최소한 하나의 광고 할당이 활성화되어야 게시된다.

비즈니스 도메인 모델링

• 유비쿼터스 언어를 발전시켜 비즈니스 도메인 모델을 구축해야함
• 모델은 소프트웨어가 해결하고자 하는 특정 문제를 해결하는데 필요한 만큼의 비즈니스 도메인 관점을 포함

3장 도메인 복잡성 관리

도메인 언어에서 같은 단어여도 사용처에 따라 다른 의미로 사용되는 경우가 있음

• ex) lead (리드)
  • 마케팅 부서 - 누군가 제품중 하나에 관심이 있다는 알림
  • 영업 부서 - 영업 프로세스의 전체 수명주기

바운디드 컨텍스트

• 모델의 경계(바운디드 컨텍스트)를 정의하여 유비쿼터스 언어의 일관성을 유지할 수 있음
• 마케팅 컨텍스트와 영업 컨텍스트로 분할하여 각 경계 안에서 리드라는 용어를 사용하게함
• 유비쿼터스 언어의 범위를 정의하는 것은 전략적인 설계 의사결정으로 이에 따라 모델의 크기를 정할 수 있음

4장 바운디드 컨텍스트 연동

• 다른 바운디드 컨텍스트의 모델은 서로 독립적으로 발전하고 구현될 수 있지만, 바운디스 컨텍스트 자체는 독립적이지 않으며 서로 상호작용해야함
• 바운디드 컨텍스트끼리 연동이 필요할 때 설계패턴을 알아보자

협력형 패턴 그룹

소통이 잘 되는 팀간의 협력에 적합

파트너십 패턴

• 한 팀은 다른 팀에 API의 변경을 알리고 다른 팀은 충돌없이 받아들임
• 양팀에서 연동의 조정과 적절한 솔루션 선정
  공유 커널 패턴
• 하위 도메인의 동일 모델 혹은 일부가 여러 다른 바운디드 컨텍스트에서 구현되는 경우 공유 커널과 같이 공유 모델을 사용할 수 있음
• 바운디드 컨텍스트 간에 강한 의존관계를 만들기 때문에 중복 비용이 조율 비용보다 클 경우에 적용해야함

사용자-제공자 패턴 그룹

서비스를 제공하는 업스트림과 이를 사용하는 다운스트림으로 나눠진 패턴

순응주의자 패턴

• 다운스트림 팀이 업스트림 팀의 모델을 받아들이는 패턴

충돌 방지 계층 패턴

• 충돌 방지 계층을 둬서 업스트림 모델을 스스로의 필요에 맞게 가공하여 사용
  

오픈 호스트 서비스 패턴

• 구현모델의 변경으로부터 사용자를 보호하기 위해 업스트림에서 퍼블릭 인터페이스와 구현 모델을 분리하여 다운스트림에 영향을 주지 않으면서 구현을 발전시킬 수 있음
• 충돌 방지 계층 패턴의 반대

분리형 노선

• 서로 협력하지 않는 것으로 커뮤니케이션 이슈가 있거나 기능 중복이 협업보다 비용이 저렴한 경우, 혹은 모델의 차이가 너무 다른경우 분리된 길을 가게 됨
• 핵심 하위 도메인 연동시 피해야할 패턴

시스템의 바운디드 컨텍스트 간의 연동 패턴을 분석해 컨텍스트 맵으로 관리