Bounded Context (22.09.16 TIL)

 오늘 코딩 인터뷰 시간 때 배운 개념을 정리해보려고 한다.

 애플리케이션을 개발할 때 우리는 다양한 도메인 용어를 사용한다. 객체는 '현실세계의 은유를 통한 새로운 소프트웨어 세계의 창조'라는 관점에서, 현실 세계인 도메인에서 사용되는 이름들을 객체에 부여하는 것이다. 

 그런데 평소에 코드를 짤 때도 변수명을 올바르게 짓는 것이 중요하다는 것은 알았지만 정확히 왜 중요한 지는 알지 못했었다. 변수명이 겹치면 안 좋으니까~ 변수명을 제대로 써야 코드 읽을 때 편하니까~ 정도로만 이해하고 있었기 때문에 오늘 bounded context를 홀맨이 말씀해 주셨을 때도 의문점이 들어 질문을 했었다. 

 질문 내용을 말하기 전에 먼저 bounded context 는 무엇인지 말해보자면, 애플리케이션의 전체적인 구조를 보면 다양한 도메인에서 같은 용어가 많이 발생하는 걸 볼 수 있는데 이렇게 용어의 중복이 많아지게 되면 다른 기능을 수행해야 하는 파트에서 하나의 모델로 처리하려는 시도가 있을 수 있다. 같은 용어라도 하위 도메인마다 의미가 다른 경우가 있는데 예를 들어 Account 라는 네이밍은 은행 측면에서는 '계좌'라는 개념으로 통용되고, 회원가입 측면에서는 '계정'이라는 개념으로 통용된다. 만약 두 파트가 한 팀에 있다고 할 때 동시에 계좌와 계정이라는 객체를 Account로 만들면 어떻게 될까? 아무리 구분해서 사용하려는 노력이 있다고 해도 반드시 해당 도메인에 안 좋은 영향을 끼치게 될 것이다. 모델은 특정한 콘텍스트 (문맥)에서 완전한 의미를 갖는데, 이렇게 구분되는 경계를 갖는 콘텍스트를 bounded context라고 한다.

 그래서 현업에서는 이러한 불필요한 의미 충돌을 줄이기 위해 팀을 (임의로 말해보면) 회원가입팀, 계좌팀으로 나누어서 일을 진행한다고 한다. 여기서 의문이 생겼던게 굳이 왜? 였다. 그냥 한쪽이 Account 대신 다른 네이밍을 쓰면 되는 것 아닌가? 꼭 똑같은 도메인명으로 해서 팀을 나누는 대공사까지 해야 하나? 

 하지만 엄밀히 말하자면 도메인이란 사용자들이 관심을 가지고 있는 특정 분야나 주제이기 때문에 실제 도메인의 규칙과 제약을 최대한 유사하게 반영하는 것이 핵심이다. 아래는 마틴 파울러의 도메인 혼용에 관한 구문이다.

As you try to model a larger domain, 
it gets progressively harder to build a single unified model. 
Different groups of people will use subtly different vocabularies in different parts of a large organization.

더 큰 도메인을 모델링하려고 하면 할수록 단일 통합 모델을 구축하기가 점점 더 어려워집니다. 
다른 그룹의 사람들은 대규모 조직의 다른 부분에서 미묘하게 다른 어휘를 사용합니다. 
모델링의 정밀도는 이에 빠르게 영향을 미치며 종종 많은 혼란을 야기합니다.

- 마틴 파울러

 도메인은 사람들의 머릿속에 공통적으로 공유되는 분야가 있기 때문에 멘탈 모델이라고도 한다. 회원가입 팀에서는 Account는 당연히 계정의 의미이고, 계좌 팀에서는 당연히 계좌의 의미이다. 만약 모든 인사팀/영업팀/계좌팀/회계팀 등의 기능이 한 코드에 넣어져 있다면? 제대로 된 인수인계 없이 개발에 참여하게 된 회원가입 쪽의 개발자가 계좌 쪽의 Account를 사용한다면? 대형사고가 될 것이다. 이러한 백그라운드를 듣다 보니 바로 납득이 되면서 사람들의 머릿속에 공유되는 공통된 생각이라는 개념은 정말 힘이 센 녀석이구나,, 라는 생각이 들었다. 아직 갈 길이 멀다 화이팅,,!!!