도메인 주도 설계 방법(Domain-Driven Design; DDD)은 크게 전략적 설계와 전술적 설계 두가지로 나눌 수 있다.
1.
전략적 설계 - What? Why? 어떤 소프트웨어를, 왜 만드는지
2.
전술적 설계 - How? 소프트웨어 각각의 구성요소가 구현되는 방법
먼저 전략적 설계 관점에서 도메인 주도 설계의 패턴과 원칙을 탐색해보자.
1장 비즈니스 도메인 분석하기
비즈니스 도메인
•
기업의 주요 활동 영역으로, 일반적으로 회사가 고객에게 제공하는 서비스
•
ex) 아마존 - 소매업 & 클라우드 서비스
하위 도메인
비즈니스 도메인의 목표를 달성하기 위해 세분화된 영역으로 하위 도메인끼리 상호작용을 해야 함
•
핵심 하위도메인
◦
경쟁업체와 차별화된 서비스로 새로운 제품이나 기존 프로세스를 최적화하여 비용을 줄이는 것
◦
회사의 수익성이 좌우되기 때문에 경쟁업체가 최대한 모방하기 어렵고 복잡한 문제를 해결해야 함
◦
요구사항이 자주 지속적으료 변경될 것이므로 솔루션은 유지보수가 가능하고쉽게 개선될 수 있어야함
•
일반 하위 도메인
◦
모든 회사가 같은 방식으로 수행하는 비즈니스 활동
◦
복잡하지만 이미 많은 사람들이 고민하고 해결하기 위해 시간을 투자했기 때문에 맞춤형 솔루션이 어느정도 나와있고 이로인해 경쟁력이 없음
◦
제품을 구입하나 오픈소스 솔루션을 채택하는 것이 효율적
•
지원 하위 도메인
◦
회사의 비즈니스를 지원하는 활동으로 경쟁 우위 없고 이미 만들어진 솔루션을 활용
◦
기본적인 ETL작업과 CRUD 인터페이스를 가진 명확한 비즈니스 로직
2장 도메인 지식 찾아내기
•
효과적인 소프트웨어 솔루션을 설계하려면 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야 함
•
전통적인 소프트웨어 개발 생애주기
◦
도메인 지식 > 분석모델 > 요구사항 > 시스템 설계 > 소스코드
•
이 같은 과정에서는 도메인 지식이 종종 왜곡된 상태로 소프트웨어 엔지니어에게 전달되어 잘못된 솔루션을 구현하게 됨
유비쿼터스 언어
•
효과적 소통을 위해 변환에 의존하지 말고 같은 언어를 사용하여 도메인 전문가와 소프트웨어 엔지니어 사이의 간극을 메워야 함
•
기술용어를 빼고 비즈니스 도메인에 관련된 용어로만 구성하여 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해 할 수 있는 관점으로 표현
예시)
비즈니스 도메인 모델링
•
유비쿼터스 언어를 발전시켜 비즈니스 도메인 모델을 구축해야함
•
모델은 소프트웨어가 해결하고자 하는 특정 문제를 해결하는데 필요한 만큼의 비즈니스 도메인 관점을 포함
3장 도메인 복잡성 관리
도메인 언어에서 같은 단어여도 사용처에 따라 다른 의미로 사용되는 경우가 있음
•
ex) lead (리드)
◦
마케팅 부서 - 누군가 제품중 하나에 관심이 있다는 알림
◦
영업 부서 - 영업 프로세스의 전체 수명주기
바운디드 컨텍스트
•
모델의 경계(바운디드 컨텍스트)를 정의하여 유비쿼터스 언어의 일관성을 유지할 수 있음
•
마케팅 컨텍스트와 영업 컨텍스트로 분할하여 각 경계 안에서 리드라는 용어를 사용하게함
•
유비쿼터스 언어의 범위를 정의하는 것은 전략적인 설계 의사결정으로 이에 따라 모델의 크기를 정할 수 있음
4장 바운디드 컨텍스트 연동
•
다른 바운디드 컨텍스트의 모델은 서로 독립적으로 발전하고 구현될 수 있지만, 바운디스 컨텍스트 자체는 독립적이지 않으며 서로 상호작용해야함
•
바운디드 컨텍스트끼리 연동이 필요할 때 설계패턴을 알아보자
협력형 패턴 그룹
소통이 잘 되는 팀간의 협력에 적합
파트너십 패턴
•
한 팀은 다른 팀에 API의 변경을 알리고 다른 팀은 충돌없이 받아들임
•
양팀에서 연동의 조정과 적절한 솔루션 선정공유 커널 패턴
•
하위 도메인의 동일 모델 혹은 일부가 여러 다른 바운디드 컨텍스트에서 구현되는 경우 공유 커널과 같이 공유 모델을 사용할 수 있음
•
바운디드 컨텍스트 간에 강한 의존관계를 만들기 때문에 중복 비용이 조율 비용보다 클 경우에 적용해야함
사용자-제공자 패턴 그룹
서비스를 제공하는 업스트림과 이를 사용하는 다운스트림으로 나눠진 패턴
순응주의자 패턴
•
다운스트림 팀이 업스트림 팀의 모델을 받아들이는 패턴
충돌 방지 계층 패턴
•
충돌 방지 계층을 둬서 업스트림 모델을 스스로의 필요에 맞게 가공하여 사용
오픈 호스트 서비스 패턴
•
구현모델의 변경으로부터 사용자를 보호하기 위해 업스트림에서 퍼블릭 인터페이스와 구현 모델을 분리하여 다운스트림에 영향을 주지 않으면서 구현을 발전시킬 수 있음
•
충돌 방지 계층 패턴의 반대
분리형 노선
•
서로 협력하지 않는 것으로 커뮤니케이션 이슈가 있거나 기능 중복이 협업보다 비용이 저렴한 경우, 혹은 모델의 차이가 너무 다른경우 분리된 길을 가게 됨
•
핵심 하위 도메인 연동시 피해야할 패턴
시스템의 바운디드 컨텍스트 간의 연동 패턴을 분석해 컨텍스트 맵으로 관리