고객과 함께 하는 도메인 특화 언어 DSL

1부 내러티브 1장 도입 예제 나는 글을 쓸 때, 먼저 무엇에 대해 글을 쓰는지 간략히 설명하곤 한다(이 책에서는 DSL(Domain-Specific Language)이 바로 그 무엇이다). 이때 구체적인 예제를 우선 보여준 다음, 이어서 예제에서 다룬 개념을 추상화하는 편이다. 이 책도 마찬가지로, 이 장에서 먼저 예제를 통해 DSL에서 나타날 수 있는 여러 가지 형태를 설명하려고 한다. 그런 후 다음 장부터 이 개념을 폭넓게 적용할 수 있게 일반화하고자 한다. 1.1 고딕양식의 보안 어릴 적에 TV에서 봤던 유치한 모험 영화들이 어렴풋하게 기억이 난다. 흔히 이런 영화에는 오래된 성, 특이한 비밀 장소, 또는 비밀 통로가 숨겨져 있었다. 영화에 등 장하는 영웅은 이 비밀 공간을 찾으려고 계단 꼭대기의 촛대를 당기거나, 벽을 두 번 두드리곤 했다. 이러한 생각을 바탕으로, 보안 시스템을 만들려는 회사를 상상해 보자. 이 회사 직원이 와서 무선 네트워크를 준비하고, 작은 장치들을 설치한다. 각 장치는 흥미 로운 일이 일어날 때 4글자로 된 메시지를 보낸다. 예를 들어 서랍에 장착된 센서는 서랍이 열릴 때 라는 메시지를 보낸다. 이들 장치 중에는 작은 제어 장치도 있는데, 이 제어 장치는 4글자로 된 명령 메시지에 반응한다. 예를 들어 제어 장치 는 라는 메시지를 받았을 때 문을 연다. 이러한 보안 시스템에서 핵심 부분은 컨트롤러 소프트웨어로, 이벤트 메시지를 받고 이 메시지로 무엇을 할지 계산한 후, 명령 메시지를 전송한다. 이 회사는 닷컴 이 붕괴할 때 자바로 제어할 수 있는 값싼 토스터를 대량 구매해서 컨트롤러로 사 용하고 있다. 그래서 고객이 고딕 보안 시스템을 구매하면, 수많은 장치와 자바로 제어할 수 있는 토스터를 가지고 가서 고객사에 맞게 만들어 주었다. 이 예제에서는 이 컨트롤러 프로그램에 주목하려고 한다. 각 고객은 자신만의 요 구사항을 가지고 있지만, 요구사항을 잘 수집해서 보면 공통적인 패턴을 쉽게 찾 을 수 있다. 예를 들어 그랜트(Grant) 양은 침실 문을 닫고, 서랍을 연 후, 등을 켜야 만 비밀 장소에 들어갈 수 있다. 쇼(Shaw) 양은 수도꼭지를 튼 후, 두 개의 비밀 장 소에 맞게 전등을 켜서 비밀 장소를 이용한다. 반면에 스미스(Smith) 양은 사무실의 자물쇠로 잠긴 옷장 안에 비밀 장소가 있다. 옷장의 자물쇠를 풀려면, 문을 닫고, 벽 에 걸린 사진을 내려놓은 후, 책상 전등을 세 차례 켜고, 서류 캐비닛의 맨 위 서랍 을 연다. 만약 스미스 양이 책상 전등을 끄지 않고 비밀 장소를 열면, 경고음이 울 린다. 비록 이 예시가 엉뚱하지만, 근본적인 요점 자체는 유별나지 않다. 요점은 이 시 스템이 구성요소와 행위 대부분을 공유하지만, 중요한 차이점도 몇 가지 있다는 사 실이다. 이 경우 고객이 컨트롤러와 메시지를 주고받는 방식은 모두 동일하지만, 이벤트와 명령 메시지가 발생하는 순서는 서로 다르다. 회사는 최소한의 노력으로 새로운 시스템을 설치할 수 있게 준비하려고 한다. 이렇게 하려면, 회사는 일련의 행동을 컨트롤러에 쉽게 프로그래밍할 수 있도록 만들어야 한다. 이들 사례를 모두 살펴보니, 컨트롤러를 상태 머신(state machine)으로 보면 효과 적일 거라는 생각이 문득 떠오른다. 각 센서는 이벤트를 전송해 컨트롤러의 상태를 바꾼다. 컨트롤러의 상태가 변할 때, 컨트롤러는 명령 메시지를 네트워크를 통해 전송한다. 이쯤에서 처음에는 이와는 반대로 글을 썼음을 밝혀야겠다. 상태 머신이 DSL의 좋은 사례였기에, 먼저 상태 머신을 선택했다. 그러고 나서 기존의 상태 머신 예제 가 지루했기 때문에, 고딕 양식의 성을 예제로 골랐다. 1.1.1 그랜트 양의 컨트롤러 이 상상 속의 회사에 만족하는 고객이 수천 명이 되더라도, 지금은 한 명에만 집중 해 보자. 바로 내가 제일 좋아하는 그랜트 양이다. 평상시에는 자물쇠로 잠근 침실 안에 비밀 장소를 숨겨 놓고 있다. 비밀 장소를 열려면, 문을 닫고, 두 번째 서랍을 연 후, 옆에 있는 등을 켜는데 순서는 중요하지 않다. 이렇게 하면, 비밀 벽이 열리 고 비밀 장소로 들어갈 수 있다. 이 순서를 상태 다이어그램으로 표현할 수 있다(그림 1.1). 상태 머신을 한 번도 배운 적이 없을 수도 있지만, 상태 머신은 행위를 기술할 때 주로 사용하는 방식이다. 보편적인 방식은 아니지만, 이 경우에는 꽤 효과적이다. 상태 머신을 적용할 때 밑바탕에 깔린 생각은 컨트롤러가 다양한 상태에 있을 수 있다는 점이다. 컨트롤러가 특정 상태에 있을 때 특정 이벤트가 일어나면, 다른 상 태로 전이(transition)하며, 이 상태에서도 다른 상태로 전이할 수 있다. 이벤트가 연 속적으로 발생하면, 결국 컨트롤러는 여러 상태들 사이로 이동하게 된다. 이 모델 에서, 액션(컨트롤러에서 명령어 전송)은 해당 상태로 진입할 때 발생한다. (상태 머신 종류에 따라 액션이 발생하는 위치는 다르다.) 이 컨트롤러는 간단하고, 대부분은 전형적인 상태 머신을 따랐지만, 약간 변형한 부분이 있다. 이 컨트롤러는 별도의 유휴 상태(idle state)를 가지며, 시스템은 대부 분의 시간을 이 상태에서 보낸다. 특정 이벤트는 시스템을 유휴 상태로 바로 되돌 려, 모델을 리셋할 수 있다. 심지어는 시스템에서 상태가 전이하는 도중에도 리셋 할 수 있다. 이처럼 상태 머신에 리셋 이벤트를 추가하게 되면, 전통적인 의미의 상태 머신 모델 범주에는 포함되지 않는다. 상태 머신을 변형한 모델에는 여러 종류가 있고, 꽤 널리 쓰인다. 이 모델은 그중 하나를 본떠서 만들었지만, 리셋 이벤트를 추가해 예제 특유의 상황에 맞게 변형했다. 특히 주목할 점은, 리셋 이벤트가 없더라도 그랜트 양의 컨트롤러를 표현할 수 있다는 점이다. 리셋 이벤트를 사용하지 않고, 이벤트로 촉발되 어 유휴 상태로 돌아가는 전이를 모든 상태에 추가할 수도 있다. 하지만 리셋 이 벤트를 사용하면 다이어그램을 단순하게 만들 수 있으므로 효과적이다. 1.2 상태 머신 모델 팀에서 상태 머신을 사용하여 컨트롤러가 동작하는 방식을 효과적으로 추상화 할 수 있다고 결정했다면, 다음 단계로 이 추상화가 소프트웨어 자체에 확실히 스며들도록 해야 한다. 팀원이 컨트롤러가 동작하는 방식을 이벤트, 상태, 전이 를 통해 이해했다면, 이들 용어가 소프트웨어 코드에도 그대로 나타나기를 원한 다. 사실 이는 유비쿼터스 언어(Ubiquitous Language)[Evans DDD]에서 말하는 도메인 주도 설계(Domain-Driven Design) 원칙이다. 즉, 이 작업은 도메인 전문 가와 프로그래머가 공유하는 언어를 만드는 일이다. 자바로 작업할 때 이처럼 공통 용어를 만들 수 있는 자연스러운 방법으로, 도 메인 모델(Domain Model)[Fowler PoEAA]을 이용해 상태 머신을 만들 수 있다. 컨트롤러는 여러 장치와 통신할 때, 이벤트 메시지를 받아 커맨드 메시지를 전송한다. 이들 메시지는 4글자로 된 코드이며, 통신 채널을 통해 전송된다. 컨 트롤러 소스 코드에서 이들 메시지를 코드가 아니라, 의미 있는 이름을 사용해 참조하기를 원한다. 그래서 Event 클래스와 Command 클래스에 코드(code)뿐 만 아니라, 이름(name)을 추가했다. 나는 이들 클래스를 서로 분리했는데(같은 슈 퍼 클래스를 사용해), 이 두 클래스가 컨트롤러 코드에서 서로 다른 역할을 하기 때 문이다. class AbstractEvent... private String name, code; public AbstractEvent(String name, String code) { this.name = name; this.code = code; } public String getCode() { return code;} public String getName() { return name;} public class Command extends AbstractEvent public class Event extends AbstractEvent State 클래스에는 해당 상태에서 전송하는 커맨드와 외부로 향하는 전이를 저장 한다. class State... priva…

출처: 국립중앙도서관 서지정보