Skip to content

Latest commit

 

History

History
236 lines (110 loc) · 10.9 KB

02. 도메인 지식 찾아내기.md

File metadata and controls

236 lines (110 loc) · 10.9 KB

정리

비즈니스 문제를 해결하기 위해 단일화된 언어를 사용하고 지속적인 발전이 필요하다.

운영환경에 배포되는 것은 도메인 전문가의 지식이 아니라 개발자의 이해 혹은 오해다.

비즈니스 문제

우리가 개발하는 소프트웨어 시스템은 비즈니스 문제를 해결하는 솔루션이다.

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

비즈니스 문제는 비즈니스 도메인과 하위 도메인의 모든 수준에서 발생할 수 있다.

하위 도메인은 세분화된 문제 도메인(problem domain)으로 특정 비즈니스 기능에 대한 솔루션을 제공하는 것이 목적이다.

도메인 지식 찾아내기

도메인 전문가를 이해하고 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이 중요하다.

효과적인 소프트웨어는 도메인 전문가의 멘탈 모델을 모방해야 한다.

비즈니스 문제와 요구사항 이면에 있는 이유에 대한 이해가 없다면 솔루션은 비즈니스 요구사항을 소스코드로 '번역'한 것에 불과하다.

소프트웨어 프로젝트의 성공은 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에 달렸다.

문제를 해결하려면 문제를 이해해야 한다.

커뮤니케이션

결과는 모든 참여자가 얼마나 잘 협력할 수 있느냐에 달려있다.

프로젝트와 연관된 모든 것에 대한 합의와 일치는 프로젝트의 성공에 필수다.

하지만 대부분 프로젝트에서 효과적인 커뮤니케이션을 목격하기 힘들고 도메인 전문가가 도메인 지식을 일방적으로 엔지니어에게 전달한다.

전형적인 소프트웨어 개발 생애주기에서 도메인 지식은 분석 모델(Analysis Model)로 알려진 엔지니어 친화적인 형태로 '변환'된다.

모든 변환은 정보를 잃게 만들어 중요한 도메인 지식이 손실된다.

문서화된 커뮤니케이션은 최신 정보를 담아내지 못한다.

이렇게 되면 소프트웨어 프로젝트는 실패한다.

유비쿼터스 언어란 무엇인가?

전통적인 소프트웨어 개발 생애주기에서 일어나는 변환은 다음과 같다.

  1. 도메인 지식이 분석 모델로
  2. 분석 모델이 요구사항으로
  3. 요구사항은 시스템 설계로
  4. 시스템 설계는 소스코드로

도메인 주도 설계는 도메인 전문가가 소프트웨어 엔지니어에게 지식을 전달하기 위한 더 나은 방법으로 유비쿼터스 언어를 제안했다.

이는 도메인 주도 설계의 초석으로 변환에 의존하지 않고 비즈니스 도메인을 설명하기 위한 단일화된 언어를 사용하는 것이다.

모든 프로젝트 참가자의 공통된 이해는 오직 유비쿼터스 언어와 그 용어의 지속적인 사용을 통해서만 함양될 수 있다.

비즈니스 언어

유비쿼터스 언어는 비즈니스 언어이기 때문에 기술 용어는 빼고 비즈니스 도메인에 관련된 용어로만 구성해야 한다.

유비쿼터스 언어의 목표는 도메인 전문가의 이해와 비즈니스 도메인에 대한 멘탈 모델을 쉽게 이해할 수 있는 관점으로 표현하는 것이다.

시나리오

  • 광고 캠페인은 다양한 창의적인 자료를 전시할 수 있다.
  • 캠페인은 최소한 하나의 광고 할당이 활성화되어야 게시된다.
  • 판매 커미션은 거래가 승인된 후에 회계 된다.

광고 캠페인 관리 시스템에 대한 문장을 비즈니스 언어로 작성한 것이다.

반면에 다음 문장은 기술적인 언어로 작성해 도메인 전문가가 이해하기에 명확하지 않다.

또한 개발자는 비즈니스 로직을 완전히 이해할 수 없어 효과적으로 솔루션을 구현하는 능력이 제한된다.

  • 광고의 아이프레임(iframe)은 HTML 파일을 표시한다.
  • 캠페인은 '활성-할당(active-placement)' 테이블에서 하나의 연관 레코드가 있어야 게시된다.
  • 판매 커미션은 거래(transaction) 테이블과 판매-승인(approved-sales) 테이블의 연관 레코드에 근거하여 처리된다.

일관성

유비쿼터스 언어는 반드시 정확하고 일관성이 있어야 한다.

모호한 언어

어떤 비즈니스 도메인에서 정책이라는 용어가 규제 규칙 또는 보험 계약과 같은 여러 의미를 가진다.

소프트웨어는 모호성에 잘 대처하지 못하며 '정책'이라는 개체를 코드로 모델링하기 어려울 수 있다.

따라서 '정책'의 경우 '규제 규칙'과 '보험 계약'의 두 용어를 사용하여 명확한 모델을 만들어야 한다.

동의어

유비쿼터스 언어에서 두 용어는 서로 바꿔 사용할 수 없다.

동의어는 처음에 해로워 보이지 않을 수 있지만 각각 서로 다른 역할을 가지고 다른 행동을 한다.

용어의 차이점을 이해하고 특정 컨텍스트 안에서 각각의 용어를 사용하는 것이 바람직하다.

비즈니스 도메인 모델

모델이란 무엇인가?

모델이란 사물이나 현상에서 의도한 관점만 강조하고 다른 측면은 무시하여 간략히 표현한 것이다. 즉, 특정 용도를 마음에 둔 추상화의 결과다.

모델은 실세계의 복제가 아니라 우리가 실제 시스템을 이해하는 데 도움을 주는 것이다.

세부적인 모든 것을 나타내는 것이 아닌 특정 목적을 지원하기 위해 나타내는 것이다.

예를 들어 길 안내 지도, 지형도, 세계 지도, 지하철 노선도 등 지도는 일종의 모델이다.

효과적인 모델링

모든 모델에는 목적이 있고 효과적인 모델은 그 목적을 달성하는 데 필요한 세부사항만 포함한다.

즉, 유용한 모델은 실세계의 복사본이 아니라 문제를 해결하려는 의도가 있으며, 그 목적에 필요한 정보만 제공해야 한다.

모델은 본질적으로 추상화의 결과다.

추상화의 목적은 모호함이 아니라 절대적으로 정확할 수 있는 새로운 의미론적 수준(semantic level)을 만드는 것이다.

비즈니스 도메인 모델링

유비쿼터스 언어를 발전시키는 것은 비즈니스 도메인 모델을 구축하는 것이다.

모델은 도메인 전문가의 사고 프로세스인 멘탈 모델을 반영해야 한다.

유비쿼터스 언어는 도메인의 모든 상세 정보를 포함하는 게 아닌 해결하고자 하는 문제를 해결하는 데 필요한 만큼의 비즈니스 도메인 관점을 포함하면 된다.

엔지니어링 팀과 도메인 전문가의 효과적인 커뮤니케이션을 위해 도메인 전문가가 이해할 수 있는 비즈니스 언어로 대화해야 한다.

지속적인 노력

유비쿼터스 언어를 정형화하려면 언어의 소유자인 도메인 전문가와의 상호작용이 필요하다.

모든 이해관계자는 프로젝트 전반에 걸쳐 모든 커뮤니케이션에 유비쿼터스 언어를 지속적으로 사용해 지식 공유를 확산해야 한다.

유비쿼터스 언어를 발전시키는 것은 진행형이다.

획기적인 발전에 따라 새롭게 얻은 도메인 지식에 맞춰 유비쿼터스 언어 또한 발전해야 한다.

도구

위키는 유비쿼터스 언어를 수집하고 관리하는 용어집(glossary)으로 사용될 수 있다.

중앙 집중식 방식과 반대로 다 함께 용어집을 유지보수해야 한다.

용어집은 '명사'를 표현할 때 효과적이지만 '행동'을 표현하는 것은 어렵다.

단순히 명사와 관련된 동사의 목록이 아닌 규칙, 가정, 불변성을 가진 실제 비즈니스 로직은 문서화하기 어려워 유스케이스 또는 거킨 테스트(Gherkin Test)처럼 다른 도구와 함께 사용하는 것이 좋다.

거킨 언어(Gherkin Language)로 작성된 자동화 테스트는 유비쿼터스 언어를 표현하기 좋고 도메인 전문가는 테스트를 읽고 시스템의 기대 행동을 검증할 수 있다.

Scenario: 에이전트에게 새로운 지원 케이스에 대해 알린다.
	Given: 빈센트 줄수는 다음 내용을 담은 새로운 지원 케이스를 제출한다: 
	"""
	나는 AWS Infinidash를 설정하는 데 도움이 필요하다
	"""
	When: 티켓이 울프 씨에게 할당된다.
	Then: 에이전트는 새로운 티켓에 대해 알림을 받는다.

프로젝트 초기 단계에서는 어려울 수도 있지만 복잡한 비즈니스 도메인일 경우 확실히 가치가 있다.

유비쿼터스 언어의 용어의 사용을 검증할 수 있는 NDepend와 같은 정적 코드 분석 도구도 있다.

프로세스나 도구보다 개인과 상호작용이 우선이다.

도전과제

대부분의 경우 가장 중요한 지식은 문서화되거나 코드로 작성되지 않고 도메인 전문가의 정신에만 존재한다.

도메인 전문가에게 질문하는 것은 단순히 지식을 발견하는 것뿐만 아니라 도메인 전문가와 협력해서 모델을 함께 만들어가는 것이 포함된다는 사실을 알게된다.

비즈니스 도메인의 충돌과 공백을 찾아내 명확하게 할 수 있고 도메인 전문가가 자신의 영역을 더 잘 이해하도록 돕는 상호보완적인 배움의 과정이기도 하다.

조직에서 이미 사용하고 있는 언어가 DDD의 원칙을 따르지 않아 비즈니스 도메인을 효과적으로 반영하지 않을 수 있다.

이때 인내심을 가지고 문서화나 소스코드와 같이 제어하기 쉬운 부분부터 올바른 언어를 사용해야 한다.

비즈니스 도메인 엔티티의 이름은 영어 명사로 해야 코드에서도 쉽게 동일한 용어를 사용하게 된다.

결론

효과적인 커뮤니케이션과 지식 공유는 성공적인 소프트웨어 프로젝트에 필수다.

소프트웨어 엔지니어는 성공적인 개발을 위해 반드시 비즈니스 도메인을 이해해야 한다.

도메인 주도 설계의 유비쿼터스 언어는 도메인 전문가와 소프트웨어 엔지니어의 지식 간극을 메워주는 효과적인 도구로 커뮤니케이션과 지식 공유를 강화한다.

유비쿼터스 언어를 육성하는 것은 지속적인 과정이고 모호성과 암묵적 가정을 제거해 일관성이 있어야 한다.

효과적인 유비쿼터스 언어의 전제조건은 언어를 사용해야 한다는 것이다.

느낀점

도메인 전문가와 소프트웨어 엔지니어와의 원활한 소통을 위해 유비쿼터스 언어를 사용해야 한다.

비즈니스 문제를 해결할 수 있는 도메인의 핵심적인 지식은 도메인 전문가에게 있기 때문에 그들과의 끊임없는 커뮤니케이션과 지식 공유가 필요하다.

또한 도메인 전문가에게 끊임 없이 질문하고 효과적인 모델링을 위해 노력해야 한다.