[DDD]대규모 구조 #2

KNOWLEDGE LEVEL

정의

• 더 넓은 범위의 규칙으로 제약되기 전까지 모델의 특정 부분을 사용 자의 손에 맡겨야 할 때 생기는 문제를 해결한다.
• 구성가능한 행위를 갖춘 소프트웨어의 요구사항을 다루는데, 여기서 구성 가능하다는 것은 여러 ENTITY 간의 역할과 관계를 초기화 시점이나 실행 시점에서도 변경할 수 있어야 한다는 의미다.

문제

• Entity 간의 역할과 관계가 각 상황마다 다양하게 작용하는 애플리케이션에서는 복잡성이 증가 할 수 있다.
• 완전히 일반화된 모델이나 고도로 맞춤화가 가능한 모델도 사용자의 욕구를 충족하지 못한다.
• 객체는 다양한 경우를 다루고자 다른 타입을 참조하거나, 아니면 각종 상황에서 여러 가지 방법으로 쓰일 속성을 갖게된다.
• 데이터와 행위가 동일한 클래스가 단지 다양한 조립 규칙을 수용할 목적으로 크게 늘어날지도 모른다.

해결

• 기본적인 모델의 구조와 행위를 서술하고 제약하는 데 쓸 수 있는 별도의 객체 집합을 만들어라.
• 관심사를 두 가지 수준으로 분리해서 하나는 매우 구체적으로 만들고 다른하나는 사용자나 관리자의 맞춤화가 가능한 규칙과 지식을 반영해서 만들어라.

PLUGGABLE COMPONENT FRAMEWORK

문제

• 모두 같은 추상화에 기반을 두지만 서로 독립적으로 설계돼 있는 다양한 종류의 애플리케이션이 상호운용돼야 할 때 여러 BOUNDED CONTEXT 사이의 번역 때문에 통합이 제한된다.
• SHARED KERNEL은 서로 긴밀하게 일하지 않는 팀에는 맞지 않다.
• 중복과 단편화는 개발과 설치 비용을 높이고 상호운용성은 매우 달성하기 어려워진다.

해결

• 인터페이스와 상호작용에 대한 ABSTRACT CORE를 정제하라
• 인터페이스의 다양한 구현이 자유롭게 대체될 수 있는 프레임워크를 만들어라.
• 컴포넌트가 ABSTRACT CORE의 인터페이스를 통해 정확히 작동하는 한 어떠한 어플리케이션에서도 그러한 컴포넌트를 사용 할 수 있게 하라.

정리

• 이번 장에서는 대규모 구조를 이루는 패턴 나머지 부분인 KNOWLEDGE LEVEL 과 PLUGGABLE COMPONENT FRAMEWORK 에 대하여 공부하였다. 지식 수준의 경우 이전에 공부한 책임계층과 내용이 비슷하다고 생각했지만 책에서는 의존성 방향이 다르다는걸 알려줘서 두 패턴의 혼란이 정리되었다.
  PLUGGABLE COMPONENT FRAMEWORK 부분은 실제 개발하면서 생기는 문제라 공감이 많이 되었다. 책에서 제시한것처럼 적용하도록 노력해야겠다.