모델과 디자인 패턴의 연결

디자인 패턴과 도메인 패턴의 차이점 이해하기

몇몇 디자인 패턴은 도메인 패턴으로 사용할 수 있습니다. 이를 위해서는 관점의 전환이 필요합니다. 디자인 패턴은 다양한 맥락에서 흔히 겪는 문제를 해결하기 위한 설계 요소의 카탈로그를 제시했습니다.

이러한 패턴의 동기와 패턴 자체는 순전히 기술적인 용어로 표현되었습니다. 하지만, 이러한 요소들의 일부는 도메인 모델링 및 설계의 더 넓은 맥락에서 적용될 수 있습니다.

디자인 패턴 외에도 여러 기술적 설계 패턴이 발표되었습니다. 이 중 일부는 도메인에서 나타나는 깊은 개념에 해당합니다. 이러한 작업을 활용하기 위해서는 패턴을 두 가지 수준에서 동시에 봐야 합니다. 하나는 코드에서 기술적 설계 패턴의 수준이고, 다른 하나는 모델에서 개념적 패턴의 수준입니다.

STRATEGY

STRATEGY 패턴은 알고리즘의 가족을 정의하고, 각각을 캡슐화하여 서로 교환할 수 있게 하는 것입니다. STRATEGY는 알고리즘을 사용하는 클라이언트로부터 독립적으로 변할 수 있게 합니다.

도메인 모델에는 기술적으로 동기화되지 않고 실제로 문제 도메인에서 의미 있는 프로세스가 포함되어 있습니다. 대체 프로세스를 제공해야 할 때, 적절한 프로세스를 선택하는 복잡성이 여러 프로세스 자체의 복잡성과 결합되어 문제가 발생합니다.

따라서, 프로세스의 가변적인 부분을 모델 내의 별도 "전략" 객체로 분리합니다. 규칙 또는 대체 가능한 프로세스를 STRATEGY 설계 패턴을 따르도록 구현합니다. 여러 버전의 전략 객체는 프로세스를 수행하는 다양한 방법을 나타냅니다.

전통적인 STRATEGY의 디자인 패턴 관점은 다양한 알고리즘을 교체할 수 있는 능력에 중점을 둡니다. 도메인 패턴으로 사용할 때는 개념을 표현할 수 있는 능력, 보통은 프로세스나 정책 규칙을 표현할 수 있는 능력에 중점을 둡니다.

COMPOSITE

COMPOSITE 패턴은 객체를 트리 구조로 구성하여 부분-전체 계층을 나타냅니다. COMPOSITE는 클라이언트가 개별 객체와 객체의 구성을 동일하게 처리할 수 있게 합니다

복잡한 도메인을 모델링할 때, 중요한 객체가 부분으로 구성되어 있고, 그 부분도 부분으로 구성된 경우가 종종 있습니다. 어떤 도메인에서는 이러한 각 계층이 개념적으로 구별되지만, 다른 경우에는 모델이 이를 인식하지 않으면 개념적 관계가 손실됩니다. 또한, 중첩이 임의의 깊이를 가질 수 있는 경우도 있습니다.

도메인에 디자인 패턴을 적용할 때 가장 먼저 고려해야 할 점은 패턴의 아이디어가 도메인 개념에 적합한지 여부입니다. 관련 객체를 재귀적으로 이동하는 것이 편리한 경우가 있을 수 있지만, 그것이 진정한 전체-부분 계층인지 확인해야 합니다. 모든 부분이 동일한 개념 유형 아래에 있는 추상화를 찾았는지 확인해야 합니다.

추상 유형을 정의하여 COMPOSITE의 모든 구성원을 포함합니다. 정보를 반환하는 메서드는 컨테이너에서 구현하여 내용을 기반으로 집계 정보를 반환합니다. "잎" 노드는 자신의 값을 기반으로 이를 구현합니다. 클라이언트는 추상 유형을 처리하고 잎과 컨테이너를 구분할 필요가 없습니다.