Eternity's Chit-Chat : 유연한 설계를 위한 패턴과 원리 - 1.시간, 돈, 그리고 GENERIC SUBDOMAIN 1부

2009년 10월 30일

유연한 설계를 위한 패턴과 원리 - 1.시간, 돈, 그리고 GENERIC SUBDOMAIN 1부

시간은 돈이다

언제부터인가 시테크가 성공의 필수 요소로 인식되고 있다. 시테크의 핵심은 제한된 시간을 적절히 활용하여 최대의 성과를 올리는 것이다. 속도의 경제성을 중시하는 현대인의 삶에 있어 시간은 돈의 대체품이라 해도 과언이 아니다. 영국 워익 대학의 경제학 교수인 이안 워커는 시간을 돈으로 환산하는 방정식을 만들어 시간과 돈의 상관관계를 수식으로 제시하기도 했다. 이 수식을 사용하면 누워서 빈둥거리거나 잠을 자거나 식사를 하는 등의 모든 일상 생활에 소요되는 시간을 돈으로 계산할 수 있다.

이처럼 현대인의 삶에 있어 시간과 돈의 중요성이 커짐에 따라 시간과 돈을 절약하기 위해 사용되는 애플리케이션의 수 역시 비약적으로 증가하고 있다. 특히 다중 사용자와 대용량 데이터를 처리하는 엔터프라이즈 애플리케이션의 목표는 시간과 돈의 효율적인 처리라고 해도 과언이 아닐 것이다.

비즈니스에 따라 요구되는 정확성과 정밀성의 차이는 존재하지만 대부분의 엔터프라이즈 애플리케이션에서 시간과 돈은 중요한 도메인 개념의 일부를 구성한다. 복식 부기를 사용하는 회계 애플리케이션에서 다국적 기업 간의 거래를 처리하기 위해 통화와 시간대를 변환해야 하는 애플리케이션에 이르기까지 다수의 핵심적인 요구사항이 시간 및 돈과 관련되어 있음을 알 수 있다.

그러나 시간대의 처리와 통화 변환 자체를 애플리케이션의 핵심 도메인이라고 말할 수는 없다. 애플리케이션의 핵심 도메인 영역은 외부로 노출시키고 싶지 않은 기업의 비즈니스 정책이나 서비스 기획과 같은 기업 경쟁력과 관련된 영역이다. 지역에 따라 시간을 변환하고 각 국가 간에 통화를 변환하는 기능은 핵심 도메인 영역이라기 보다는 핵심 도메인을 지원하는 보조적인 도메인 영역이라고 할 수 있다.

시간과 돈이 엔터프라이즈 애플리케이션의 중요한 요구사항과 관련되어 있음에도 불구하고 핵심 도메인 영역은 아니기 때문에 대부분의 프로젝트에서 다음과 같은 두 가지 상반된 문제가 나타난다.

시간과 돈이 핵심 도메인 개념이 아니기 때문에 모델 내에 시간과 돈의 개념을 명시적으로 포함하지 않는다. 코드의 여러 곳에 시간과 돈을 처리하는 로직이 중복되고, 핵심 도메인과 상관 없는 계산 및 변환 알고리즘으로 인해 핵심 도메인 영역의 응집도가 낮아진다.

시간과 돈이 중요한 요구사항과 관련이 있기 때문에 도메인 모델 내에 포함시키고 관련 코드를 개발한다. 대부분의 개발자는 핵심 도메인 영역보다는 핵심 도메인과 관련성이 적은 시간 및 돈과 같은 공학적 능력을 요구하는 영역에 관심을 보이는 경향이 있다. 따라서 프로젝트의 핵심 인력이 시간 및 돈과 관련된 부분의 책임을 맡게 되고 핵심 도메인 영역은 신참자들로 채워진다. 결과적으로 핵심 도메인 영역은 경험이 적은 신참들이 작성한 낮은 품질의 코드로 가득차게 되고, 시간과 돈을 처리하는 코드는 불필요한 기능과 복잡도를 가진 오버엔지니어링 덩어리로 전락하게 된다.

CORE DOMAIN과 GENERIC SUBDOMAIN

문제의 원인은 도메인 영역을 핵심 도메인 영역과 핵심 도메인을 보조하는 서브 도메인 영역으로 분리하지 않은 것이다. 많은 개발자들은 도메인 레이어와 비도메인 레이어의 분리룰 통해 응집도 높은 각 영역들의 관심사항을 분리(separation of concerns)하고 변경의 파급 효과를 줄임으로써 시스템의 유지보수성을 향상 시킬 수 있다는 사실을 잘 알고 있다. 이를 위해 많은 엔터프라이즈 애플리케이션들이 LAYERD 아키텍처나 PIPE-AND-FILTER 아키텍처와 같이 결합도를 낮추고 응집도를 높일 수 있는 아키텍처 패턴을 적용하고 있다.

최근에 등장한 프레임워크와 기술은 도메인 영역과 비도메인 영역을 비교적 쉽게 분리할 수 있는 방법을 제공한다. 일단 도메인 영역을 외부 세계로부터 고립시킨 후에는 한발 더 나아가 도메인 영역 내부의 응집도를 어떻게 높일 것인가로 초점을 옮겨야만 한다. 그러나 대부분의 프로젝트는 도메인 영역과 비도메인 영역 간의 분리에서 더 이상의 진전을 보여주지 못한다.

앞서 언급한 바와 같이 도메인 영역 내에는 기업의 승패를 좌우하는 핵심 도메인 영역과 시간과 돈의 경우처럼 핵심 도메인을 지원하기 위해 존재하는 보조적인 도메인 영역이 존재한다. 두 영역을 구분하고 핵심 도메인 영역에 역량을 집중하되 핵심 도메인 영역이 보조적인 도메인 영역에 속하는 관심사에 의해 어지러지지 않도록 두 영역을 명확하게 분리해야 한다.

Eric Evans는 그의 저서 Domain Driven Design에서 도메인의 핵심적인 영역을 CORE DOMAIN이라고 부르고 보조적인 도메인 영역을 GENERIC SUBDOMAIN이라고 부른다. 일반적이라는 뜻의 GENERIC이라는 용어를 사용하는 이유는 CORE DOMAIN에 포함된 개념들이 특정 도메인의 전문적인 지식을 담고 있는데 반해 GENERIC SUBDOMAIN에 포함된 개념들은 상대적으로 특정 도메인에 국한되지 않는 일반적인 개념들을 다루기 때문이다.

모델의 어떤 부분은 도메인에 중요한 전문 지식을 포착하지도, 전달하지도 못하면서 복잡성만을 증가시킨다. 관련성이 없는 요소는 CORE DOMAIN을 분별하고 이해하는 것을 더욱 어렵게 만든다. 도메인만의 전문 지식이 아닌 모든 사람이 알고 있는 일반적인 원리나 현재의 주된 관심사와는 거리가 먼 보조적인 세세한 전문 지식으로 인해 모델을 발전시키기 어려워 지게 된다. 그러나 비록 이런 요소들이 일반적(generic)이라고 하더라도 시스템이 제 기능을 발휘하고 모델을 완전하게 표현하는데 있어서 필수적이다.
- Eric Evans, Domain-Driven Design

도메인 내의 핵심 영역에 포함되는 모델을 CORE DOMAIN으로 만들어 가장 높은 우선 순위를 부여하라. CORE DOMAIN은 개발팀이 설계 노력의 대부분을 쏟아 부어야 하는 애플리케이션의 핵심 영역이다. CORE DOMAIN 내에 포함되지는 않지만 CORE DOMAIN의 성공적인 구현을 위해 필요한 부분은 GENERIC SUBDOMAIN으로 만들어 CORE DOMAIN과 분리하라.

현재의 프로젝트를 시작하게 된 직접적인 동기를 제공하지 않는 응집도 높은 서브 도메인을 식별하라. 서브 도메인을 표현하는 일반적인 모델을 분리해서 별도의 모듈에 배치하라. 서브 도메인에는 CORE DOMAIN에 포함되어야 하는 전문 지식이 위치해서는 안된다.
일반적인 모델을 서브 도메인으로 분리한 후에는 서브 도메인 개발 작업에 CORE DOMAIN보다 낮은 우선순위를 부여하고 핵심 개발자를 서브 도메인 작업에 할당하는 실수를 하지 않도록 주의하라(서브 도메인 개발에 참여하는 핵심 개발자들은 도메인 지식을 거의 알지 못하게 될 것이기 때문이다). GENERIC SUBDOMAIN에 대해 기존의 솔루션(off-the-shelf soultion)을 구매하거나 이미 널리 알려져 있는 모델(published model)을 사용하는 것을 고려하라.
- Eric Evans, Domain-Driven Design