12장 모델과 디자인 패턴의 연결

[jongfeel]

Chapter Twelve. Relating Design Patterns to the Model

디자인 패턴과 도메인 패턴의 차이에 대해 < 디자인 패턴 > 저자들이 쓴 책에 다음과 같이 설명한다.

패턴에 대한 시각은 어떤 것이 패턴이고 어떤 것이 아닌가를 분석하는 데 영향을 준다.
어떤 사람에게는 패턴인 것이 다른 사람에게는 기본적인 요소일 수도 있다.
...
이 책에서 논의하는 디자인 패턴은 특정한 상황에서 일반적인 설계 문제를 해결하고자
상호 교류하는 수정 가능한 객체와 클래스에 관해 설명한 것이다.
[Gamma et al. 1995, p. 3]

< 디자인 패턴 > 에 소개된 패턴 가운데 일부 패턴만을 도메인 패턴으로 사용할 수 있다.
이를 위해 < 디자인 패턴 > 에서 강조하는 내용을 도메인 패턴에 맞게 적절하게 수정해야 한다.

디자인 패턴의 일부는 도메인에서 마주치는 의미 있는 개념에 사용할 수 있다.
도메인 주도 설계에서 디자인 패턴을 활용하려면 두 가지 수준에서 패턴을 바라봐야 한다.

• 코드 내에 포함된 기술적인 측면을 다루는 디자인 패턴
• 모델 내에 포함된 개념 패턴

STRATEGY (전략, POLICY[정책]라고도 함)

Define a family of algorithms, encapsulate each one, and make them interchangeable. STRATEGY lets the algorithm vary independently from clients that use it. [Gamma et al. 1995]

도메인 모델은 기술적인 이유 보다는 실제로 도메인 관점에서 의미있는 프로세스가 존재한다.

프로세스 모델링에는 방법이 하나가 있는게 아니라 여러 개가 있을 수 있다. 여러 개 중에 하나를 고르려고 하면 프로세스의 정의는 더 어색해지고 복잡해진다. 프로세스들 끼리의 행위가 혼합되면 원래 프로세스가 지니고 있던 실제 행위가 불분명해진다.

프로세스의 중심 개념과 변경되는 부분을 분리하면 명확하게 식별할 수 있고
이는 소프트웨어 설계 커뮤니티에서 효용성이 입증된 STRATEGY 패턴을 사용할 수 있다.
STRATEGY는 모델에 포함된 하나의 개념으로 사용되며 해당 모델을 구현한 코드에 반영한다.

그러므로
프로세스에서 변화하는 부분을 별도의 strategy 객체로 분리해서 모델에 표현한다.
프로세스의 규칙과 프로세스를 제어하는 행위를 서로 분리하자.
STRATEGY 디자인 패턴에 따라 규칙이나 대체 가능한 프로세스를 구현하라.
다양한 방식으로 변형된 전략 객체는 프로세스의 서로 다른 처리 방식을 표현한다.

STRATEGY를 도메인 패턴으로 사용하는 관점에서는 프로세스 또는 정책적인 규칙과 같은 하나의 개념을 표현하는 능력에 중점을 둔다.

예제: 항로 탐색 정책

Routing Service에서 SPECIFICATION에 명시된 항목을 만족하는 상세한 Itinerary를 만든다.
빠른 목적지 혹은 저렴한 비용의 목적이 항로를 탐색한다.

Figure 12.1. A SERVICE interface with options will need conditional logic.

항로 선택을 위한 변수를 STRATEGY로 분리한다.
그러면 항로 선택 방법을 명확하게 표현 가능하고, Routing Service에 매개 변수로 전달할 수 있다.

Figure 12.2. Options determined by choice of STRATEGY (POLICY) passed as argument

Leg Magnitude Policy (구간 등급 정책)은 Leg Time Magnitude, Leg Money Magnitude 를 구현하도록 변경됐으므로
Routing Service는 시간이나 비용에 대해 값이 작은 Leg를 찾아서 조건식을 사용하지 않고 동일한 방법으로 모든 요청을 처리할 수 있다.

이 설계에서는 < 디자인 패턴 > 에서 설명하는 STRATEGY 패턴의 장점이 고스란히 담겨 있다.
이후 추가로 속도와 비용 측면에서 균형을 맞춘 항로를 선택해야 하는 경우가 있을 수 있고
다른 회사의 운송 수단이 아닌 자사 운송 수단을 사용해 화물을 운반하는 정책을 고수하는 회사라면 속도나 비용 외에 다른 요인을 가지고 항로를 선택할 수도 있다.

만약 STRATEGY를 사용하지 않고 코드 수정은 가능하지만
Routing Service 여기저기에 코드가 흩어져서 다른 코드와 엉키게 되고
Routing Service의 인터페이스에 새로운 연산이 계속 추가되서 크기가 커지게 된다.
STRATEGY 패턴으로 결합도를 줄이면 Routing Service는 깔끔해지고 테스트하기도 쉬워진다.

도메인 언어를 사용해서 Routing Service의 행위를 한 문장으로 다음과 같이 정의할 수 있다.
"Routing Service는 선택한 STRATEGY를 기반으로 Leg의 총합이 가장 적은 Itinerary를 선택한다."

---

도메인 계층에서 기술적인 디자인 패턴을 사용한다면 부가적인 동기 부여와 함께 의미 있는 계층을 추가해야 한다.
구현 기술로의 패턴은 가치가 있긴 하지만 STRATEGY를 실제 업무 전략이나 정책과 연관시킬 때 패턴은 유용한 구현 기술 이상의 가치를 지닌다.

순수하게 구현과 관련된 관심사로 STARTEGY를 사용할 경우 애플리케이션 내의 객체 수가 늘어날 수 있다는 점이다.
그게 문제라면 컨텍스트를 공유하는 상태 없는 객체로 STRATEGY를 구현해서 부담을 줄일 수 있다.
STRATEGY를 사용하는 동기는 부분적으로 다르고 그 차이점이 선택에 영향을 주더라도
디자인 패턴에 녹아 있는 경험을 마음대로 활용하는 데는 아무런 문제가 없다.

COMPOSITE (복합체)

Compose objects into tree structures to represent part-whole hierarchies. COMPOSITE lets
clients treat individual objects and compositions of objects uniformly. [Gamma et al. 1995]

계층구조상의 각 수준에서 다루는 개념에 차이가 없어도
클라이언트는 서로 다른 수준을 처리하기 위해 각기 다른 인터페이스를 사용해야 한다.
집계 정보(aggregate information)를 산출하고자 계층구조를 재귀적으로 탐색하는 작업은 매우 복잡하다.

도메인 모델에 디자인 패턴을 적용할 경우 가장 우선적으로 고려할 사항은
적용하려는 패턴의 기본 아이디어가 정말로 도메인 개념에 적합한지 여부다.

도메인 개념 간의 부분/전체 계층구조가 존재하는지
하부의 모든 부분이 실제로 동일한 유형의 개념으로 구성되는 추상화를 발견했는지에 따라
COMPOSITE을 적용해 모델의 측면을 좀더 명확하게 표현할 수 있다.

그러므로
COMPOSITE 내부에 포함된 모든 구성요소를 포괄하는 추상 타입을 정의한다.
컨테이너에 포함된 항목의 집계 정보를 반환할 수 있게 정보를 제공하는 메서드를 컨테이너에 구현하라.

COMPOSITE은 구조적인 수준에서는 패턴이지만 연산 수준까지 구체화하지는 않는다.
COMPOSITE은 계층 구조상 모든 행위가 동일하고 크고 작은 부분이 전체 구조를 투명하게 반영하는가라는 의미 있는 질문을 해볼 수 있다.

예제: 여러 항로로 구성된 배송 항로

Figure 12.3. A schematic of a "route" made up of "legs"

객체 모델을 통해 임의 개수의 구간으로 구성된 항로를 표현한다.

Figure 12.4. A class diagram of a Route made up of Legs

개발자들은 항로를 임의의, 획일화된 구간의 연속이라고 생각했었다.

Figure 12.5. The developers' conception of a route

도메인 전문가들은 항로를 5개의 논리적인 구획(segment)의 연속으로 보고 있다는 사실이 드러났다.
Figure 12.6. The business experts' conception of a route

대체 항로(subroute)의 경우 서로 연관성이 없는 독립적인 항로로 볼 수 있다.
관문 구간(door leg)은 현지에서 동원한 트럭 혹은 고객의 운반 수단을 사용할 수 있다는 점에서도 다른 점이 드러났다.

이 차이점에 대해 반영해 보면 객체 모델이 점점 복잡해지기 시작한다.

Figure 12.7. The elaborated class diagram of Route

이 시점에서 COMPOSITE을 적용해 본다.
COMPOSITE에서 하나의 항로는 다른 항로의 조합이므로 서로 다른 수준의 항로를 동일하게 다룰 수 있다.
모든 수준의 Route는 한 곳에서 다른 곳으로의 컨테이너 운반을 의미하므로 개념상으로도 맞다.

Figure 12.8. A class diagram using COMPOSITE

모델은 정적인 클래스 다이어그램 이상을 표현한다.
12.9의 다이어그램과 코드로 두 개념을 조합하는 방법에 관한 정보를 전달할 수 있다.
이 모델은 서로 다른 종류의 "Route" 사이의 깊은 관련성을 포착한다.

Figure 12.9. Instances representing a complete Route

아직까지 항로의 한 쪽 끝을 잘라 새로운 끝에 연결하거나
세부사항을 임의의 깊이로 중첩시키거나 하는 다양한 부가 기능을 활용할 수 있다.

아직 까지는 그런 부가 기능은 필요하지 않거나 드러나지 않았다.
항로 구획과 관문 구간이 필요하기 전 까지는 COMPOSITE을 적용하지 않고도 작업 진행이 가능하다.
디자인 패턴은 정말로 필요한 경우에만 적용해야 한다.

그렇다면 FLYWEIGHT는?

FLYWEIGHT는 도메인 모델과는 전혀 관련이 없는 디자인 패턴의 좋은 예다.

VALUE OBJECT 집합의 경우 FLYWEIGHT로 구현하는 것은 적절할 수 있다.
VALUE OBJECT에 적용할 수 있는 구현 선택사항이지만 ENTITY에는 적용할 수 없다.

COMPSITE의 경우 모델과 구현에 모두 패턴이 적용되며,
모델과 구현 모두 적용되는 것이 도메인 패턴의 본질적인 특성이다.

기술적인 문제에 대한 기술적인 해법과 함께 개념적인 도메인에 관한 해법도 제공한다면
디자인 패턴을 도메인 패턴으로 적용하기 위한 유일한 요구사항이 된다.

[jongfeel]

예제: 항로 탐색 정책 의 마지막 설명에서

여기서도 디자인 패턴의 적용에 대한 핵심을 다시 한번 잘 설명해주고 있다.
사용하는 동기는 조금 다르고 선택에 영향을 준다고 해도
디자인 패턴에 있는 핵심적이고 중요한 경험을 사용하는데 문제가 없다고 했다.

사실 이게 맞는 표현인데
디자인 패턴, 즉 설계를 배워야 하는 초급자의 경우
디자인 패턴의 핵심을 사용한 후에 그 동기 (업무 전략이나 정책)를 끼워 맞추는 식으로 하기 때문에 문제가 발생한다.
그렇게 하는 건 올바른 디자인(설계) 가 아니라는 걸 다시 한번 기억해야 할 것이다.