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

이번 장에서는 비즈니스 도메인 분석 주제를 좀 더 깊이 있게 하위 도메인 내부에서 일어나는 일, 즉 비즈니스 기능과 로직에 초첨을 맞춘다.

효과적인 커뮤니케이션과 지식 공유를 위한 도메인 주도 설계 도구인 유비쿼터스 언어를 배우고, 이를 통해 비즈니스 도메인의 복잡성을 배우며, 비즈니스 로직을 소프트웨어 모델로 만들고 구현하는데 이를 활용한다.

비즈니스 문제

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

비즈니스 도메인에서 문제(problem)의 의미는 광범위하다.

• 워크플로와 프로세스 최적화
• 수작업 최소화
• 자원 관리
• 의사결정 지원
• 데이터 관리 등

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

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

• 지식 관리 하위 도메인: 정보를 저장하고 추출하는 프로세스
• 어음 교환 하위 도메인: 재무 거래 실행 프로세스를 최적화하는 솔루션
• 회계 하위 도메인: 기업의 자금을 관리하는 솔루션

도메인 지식 찾아내기

효과적인 소프트웨어 솔루션을 서례하려면 적어도 기본적인 비즈니스 도메인 지식이 있어야한다.

이러한 지식은 도메인 전문가의 몫으로, 개발자가 도메인 전문가가 되는 것은 비효율적이다.

따라서 도메인 전문가를 이해하는 것이 더 효율적이며, 이를 위해 그들이 쓰는 동일한 비즈니스 용어를 사용하는 것이 중요하다.

효과적은 소프트웨어는 도메인 전문가가 문제를 생각하는 방식, 즉 멘탈 모델을 모방해야한다.

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

알베르토 브랜돌리니는 소프트웨어 개발은 배우는 과정이고, 작동하는 코드는 그 부산물이라고 설명한다.

이는 소프트웨어 프로젝트의 성공은 문제 해결을 위해 문제를 배우는(이해하는) 것이 중요하다고 해석될 수 있고, 이는 도메인 전문가와 소프트웨어 엔지니어 간의 효과적인 지식 공유에 달렸다.

결국 소프트웨어 엔지니어와 도메인 전문가의 효과적인 지식 공유를 위해 효과적인 커뮤니케이션이 필요하다.

커뮤니케이션

거의 모든 소프트웨어 프로젝트에는 도메인 전문가를 비롯한 다양한 역할의 이해관계자의 협업이 필요하다.

• 엔지니어, 디자이너, 프로젝트 매니저, 테스터, 분석가 등

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

• 해결하려는 문제에 대해 모든 이해관계자가 동의하고 있는가?
• 개발하고 있는 솔루션의 기능 또는 비기능 요구사항 중 서로 충돌하는 가정이 있는가? 등

모든 참여자의 협력을 이끌어내기 위해 프로젝트와 연관된 모든 것에 대한 합의와 일치는 프로젝트의 성공에 필수이다.

효과적인 커뮤니케이션이 필수적이지만 소프트웨어 프로젝트에서 찾기는 여러운데, 그 이유중 하나는 비즈니스 담당자와 엔지니어가 서로 직접 협업하지 않는 것이다.

대부분 도메인 전문가가 여러 이해 관계자를 거쳐 도메인 지식을 일반적으로 엔지니어에게 전달한다.

이러한 과정에서 도메인 지식은 분석 모델(analysis model, 명세?)로 알려진 엔지니어 친화적인 형태로 변환되어 전달되며, 이러한 과정에서 비즈니스 문제 해결에 중요한 도메인 지식이 손실된다. (반대로도 마찬가지)

이러한 문서화된 커뮤니케이션은 최신 정보를 담아내지 못하며, 결국 소스코드가 이후 프로젝트 유지관리할 엔지니어에게까지도 비즈니스 도메인 지식을 전달하는 데 사용되기 때문에 비즈니스 도메인에 대한 이해는 더욱 멀어진다.

이런 소프트웨어 개발 과정은 전화 게임과 비슷하게 점점 왜곡된 형태로 전달될 수 있고, 이런 정보는 소프트웨어 엔지니어가 잘못된 솔루션을 구현하게 하거나, 솔루션이 올바르더라도 해결하려는 문제가 잘못된 경우로 이어질 수 있다.

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

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

유비쿼터스 언어는 프로젝트 참가자들이 효과적으로 소통하기 위해 변환에 의존하지 말고 같은 언어를 사용하는 것을 의미하며, 이는 도메인 주도 설계의 초석이 된다.

“우리가 말하는 상식은 실제로 일반적이지 않다.” - Voltaire

전통적인 소프트웨어 개발 생애 주기에서 변호나이 어떻게 일어나는지 정리해보면 다음과 같다.

• 도메인 지식 -> 분석 모델
• 분석 모델 -> 요구사항
• 요구사항 -> 시스템 설계
• 시스템 설계 -> 소스코드

도메인 주도 설계에서는 도메인 지식을 계속해서 변환하는 대신, 비즈니스 도메인을 설명하기 위한 단일화된 언어 체계를 세운다(유비쿼터스 언어).

소프트웨어 프로젝트의 모든 이해 관계자는 비즈니스 도메인을 설명할 때 유비쿼터스 언어를 사용해야 하며, 핵심은 도메인 전문가가 유비쿼터스 언어를 사용해 비즈니스 도메인을 추론하는 데 편안함을 느껴야 하ㄴ다는 점이다.

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

비즈니스 언어

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

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

시나리오

광고 캠페인 관리 시스템 예시를 살펴본다.

비즈니스 언어

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

모든 문장은 비즈니스 도메인을 바라보는 도메인 전문가의 시각을 반영한다.

기술적 언어

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

순수하게 기술적이어서 도메인 전문가가 이해하기에 명확하지 않을 것이다.

개발자가 기술적인 관점에서만 비즈니스 도메인을 바라보는게 익숙하다면, 비즈니스 로직을 완전히 이해할 수 없거나, 비즈니스 로직이 왜 그렇게 운영되는지 이해할 수 없어 결국 효과적으로 솔루션을 구현하는 능력이 제한될 것이다.

• 실제 비즈니스에서 해결하려는 문제의 를 자체적인 해석을 통해 변환되므로 근본적인 이해와 멀어질 수 있다.

일관성

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

• 가정할 필요가 없어야 하고 비즈니스 도메인의 로직을 명료하게 표현해야 함

모호성이 커뮤니케이션을 방해하기 때문에 용어는 오직 하나의 의미를 가져야한다.

모호한 용어

비즈니스 도메인에서는 정책(policy)이라는 용어가 여러 의미를 가지며, 정확한 의미는 맥락에 따라 사람 간의 상호작용을 통해서만 알 수 있다.

규제 규칙, 보험 계약 이라는 정책을 예시로 들면,

소프트웨어는 이러한 모호성에 잘 대처하지 못하며, “정책"이라는 개체(entity)를 코드로 모델링하기가 어려울 수 있다.

유비쿼터스 언어는 용어마다 단일 의미를 갖게 하기 때문에 “정책"의 경우 규제 규칙(regulatory rule)과 보험 계약(insurance contract) 두 용어를 사용하여 명확한 모델을 만들어야 한다.

동의어

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

사용자라는 용어는 수많은 시스템에서 사용하지만, 도메인 전문가의 언어로 신중하게 설명하면 사용자와 방문자, 관리자, 계정 등의 다른 용어가 혼용된다는 것을 발견할 수 있다.

사용자가 맥락에 따라 다른 역할을 가지고 다른 행동을 하는 것 처럼 동의어는 대부분 맥락에 따라 다른 개념을 가지며, 이는 비즈니스 도메인에 대한 이해를 복잡하게 만들 수 있다.

따라서 특정 컨텍스트 안에서 각각의 용어를 사용해야하며, 용어의 차이점을 이해해야 간단하고 명확한 모델을 구축하고 비즈니스 도메인 객체의 구현이 가능해진다.

비즈니스 도메인 모델

모델링 관점에서 유비쿼터스 언어를 살펴보자

모델이란 무엇인가?

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

모델은 실세계의 복제가 아니라 실제 시스템을 이해하는 데 우움을 주는 인간의 창조물이다.

좋은 예시로 지도가 있다.

각 지도는 특정 목적을 지원하는 데 충분한 자료만 담고 있으며, 이 특정 목적이 해당 지도가 풀고자 하는 문제이다.

효과적인 모델링

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

• 지하철 노선도는 거리를 측정할 수 없음

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

모델은 본질적으로 추상화의 결과이며, 추상화는 불필요한 상세 정보를 생략하여 복잡한 문제를 다룰 수 있게하고 당면한 문제를 푸는 데 필요한 정보만 남게 한다.

반대로 비효과적인 추상화는 필요한 정보를 제거하거나, 불필요한 정보를 포함해 잡음을 유발하는 것이다.

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

비즈니스 도메인 모델링

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

• 비즈니스가 기능을 어떻게 구현하느냐에 대한 도메인 전문가의 사고 프로세스인 멘탈 모델을 포착해야함
• 관련된 비즈니스 엔티티와 그것의 행동, 인과 관계, 불변성 등을 반영해야함

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

이 때문에 엔지니어링 팀과 도메인 전문가의 효과적인 커뮤니케이션은 필수적이며, 비즈니스 도메인이 복잡할 수록 커뮤니케이션의 중요성은 커진다.

지속적인 노력

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

오직 실제 도메인 전문가와의 상호작용만이 비즈니스 도메인에 대한 부정확함이나 잘못된 가정, 또는 전체적인 이해 오류를 발견할 수 있다.

모든 이해관계자는 모든 커뮤니케이션에 유비쿼터스 언어를 지속적으로 사용해서 지식 공유를 확산하고 비즈니스 도메인에 대한 공유된 이해를 강화해야한다.

• 테스트, 문서화, 소스코드 자체 등

가장 중요한 점은 유비쿼터스 언어를 발전시키는 것은 진행형이라는 것으로, 지속해서 검증하고 발전시켜야 한다.

도구

유비쿼터스 언어를 수집하고 관리하는 과정을 돕는 도구와 기술이 있다.

위키

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

• 도메인의 용어에 대한 정보를 얻을 수 있는 거점 역할
• 새로운 팀원이 쉽게 적응하게 해줌

용어집을 유지보수하는 것이 매우 중요하기 때문에 유비쿼터스 언어가 변경되면 모든 팀원이 수정할 수 있게 독려해야 한다.

유스케이스 또는 거킨테스트
용어집은 장점이 명백하지만 엔티티의 이름, 과정, 역할 등의 명사(noun)에만 효과적이라는 본질적인 한계가 존재한다.

행동(behavior)은 단순히 명사와 관련된 동사의 목록이 아닌 규칙, 가정, 불변성을 가진 실제 비즈니스 로직이다.

이러한 개념은 용어집으로 문서화하기 훨씬 어렵기 때문에 용어집은 유스케이스또는 거킨테스트(Gherkin test)처럼 행동을 포착하는 데 적합한 다른 도구와 함께 사용하는 것이 좋다.

거킨테스트
거킨테스트(Gherkin Test)는 행동 주도 개발(BDD, Behavior-Driven Development)에서 사용하는 테스트 명세 언어로 개발자가 아닌 이해관계자들도 쉽게 이해할 수 있는 자연어에 가까운 형태로 테스트 시나리오를 작성할 수 있게 해줌

• Feature: 테스트할 기능이나 사용자 스토리를 설명합니다.
• Scenario: 특정 상황이나 테스트 케이스를 정의합니다.
• Given: 테스트의 전제 조건을 설명합니다.
• When: 사용자의 행동이나 이벤트를 설명합니다.
• Then: 예상되는 결과나 상태를 설명합니다.
• And, But: 추가적인 조건이나 결과를 설명할 때 사용합니다.

거긴 언어(Gherkin language)로 작성된 자동화 테스트는 유비쿼터스 언어를 포착하기에 좋은 언어일 뿐 아니라 도메인 전문가와 소프트웨어 엔지니어의 간극을 메우는 보조 도구로서의 역할을 할 수 있다.

• 도메인 전문가가 테스트를 읽고 시스템의 기대 행동을 검증할 수 있다.

1
2
3
4
5

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

거킨 기반의 테스트 스위트를 관리하는 것은 어려운 일이지만 복잡한 비즈니스 도메인의 경우 확실히 가치가 있다.

정적 코드 분석 도구

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

이런 도구들이 유용하긴 하지만 일상적인 상호작용에서 실제로 유비쿼터스 언어를 사용하는 것보다는 못하다.

애자일 매니페스토에서는 “프로세스나 도구보다 개인과의 상호작용이 우선이다.“라고 강조한다.

도전과제

질문하기

도메인 지식을 수집하는 신뢰할 만한 유일한 방법은 도메인 전문가와 대화를 하는 것이다.

대부분의 경우 가장 중요한 지식은 암묵지 이며, 이는 도메인 전문가의 정신에만 존재하므로, 여기에 접근하는 유일한 방법은 질문하는 것이다.

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

도메인 전문가라도 자신의 비즈니스 도메인에 대한 이해가 모호하거나 공백이 있을 수 있으며, 명시적 정의가 없는 비즈니스 도메인 개념을 발견할 수도 있다.

그러므로 비즈니스 도메인 특성에 대해 질문하면 종종 숨어있던 충돌과 공백을 찾아내 명확하게 할 수 있다.

개선하기

이미 프로젝트에 사용중인 도메인 관련 언어들이 DDD 원칙을 따르지 않아 비즈니스 도메인을 효과적으로 반영하지 않을 수 있다.

이러한 경우 필요한 도구는 인내심으로, 문서화나 소스코드와 같이 제어하기 쉬운 부분부터 올바른 언어를 사용한다.

영어 명사

회사에서 영어를 사용하지 않는다고 하더라도, 비즈니스 도메인의 엔티티(entity) 만큼은 영어 명사로 사용하는 것이 좋다.

• 자연스럽게 코드에서도 쉽게 동일한 용어를 사용하게 된다.

결론

효과적인 커뮤니케이션과 지식 공유는 성공적인 소프트웨어 프로젝트에 필수이며, 소프트웨어 엔지니어가 소프트웨어 솔루션을 설계하고 개발하기 위해서는 반드시 비즈니스 도메인을 이해해야한다.

유비쿼터스 언어는 도메인 전문가와 소프트웨어 엔지니어의 지식 간극을 메워주는 효과적인 도구이다.

• 대화, 문서화, 테스트, 다이어그램, 소스코드 등 프로젝트 전반에 걸쳐 모든 이해관계자가 공유된 언어를 사용함으로써 커뮤니케이션과 지식 공유를 강화할 수 있음

효과적인 커뮤니케이션을 위해 유비쿼터스 언어에서 반드시 모호성과 암묵적 가정을 제거해야한다.

• 모든 용어는 일관성이 있어야함
• 모호하지 않고 동의허가 없어야함

유비쿼터스 언어를 육성하는 것은 지속적인 과정이다.

• 프로젝트가 발전함에 따라 더 많은 도메인 지식이 발견되며 이러한 통찰이 유비쿼터스 언어에 반영되는 것이 중요함

위키 기반 용어집, 거킨 테스트 같은 도구는 유비쿼터스 언어를 문서화하고 유지보수 하는 과정을 상당히 쉽게 해주지만, 효과적인 유비쿼터스 언어의 전제 조건은 언어를 사용해야한다는 것이다.

• 모든 프로젝트 관련 커뮤니케이션에서 유비쿼터스 언어를 일관되게 사용해야함