RESPONSIBILITY LAYER (책임 계층)

[jongfeel]

RESPONSIBILITY LAYER (책임 계층)

각 개별 객체에 손수 만든 책임이 할당돼 있다면
가이드 라인도 없고, 균일함도 없고, 넓은 범위에 걸친 도메인을 동시에 다룰 능력도 없는 셈이다.
큰 모델에 응집력을 부여하려면 그러한 책임 할당에 특정 구조를 도입하는 것이 도움이 된다.

도메인을 깊이 있게 이해하면 폭넓은 패턴이 보이기 시작한다.
유용하게 만들려는 고민을 하다 보면 가장 성공적인 설계 패턴 가운데 하나인 계층화를 떠올리게 한다. (Buschmann et al. 1996)

계층은 시스템의 구획으로,
각 구획의 구성요소는 아래에 있는 계층의 서비스는 알고 이용할 수 있지만
위에 있는 계층은 알지 못하고 독립적으로 존재한다.

이런 임기응변식의 계층화는 모델에 통찰력을 부여하거나 모델링 결정을 이끌지는 못한다.

Figure 16.2. Ad hoc layering: What are these packages about?

자연적인 층이 나타나는 모델에서는 계층화와 책임 주도 설계라는 두 가지 강력한 원칙을 하나로 묶으면서
주요 책임을 기준으로 개념적 계층을 정의할 수 있다.

고수준의 책임과 계층화를 결합하면 시스템의 구성 원칙을 확보할 수 있다.

RESPONSIBILITY LAYER에 가장 잘 부합하는 계층화 패턴은 RELAXED LAYERED SYSTEM(Buschmann et al. 1996)이라고 하는 계층화의 일종인데,
이것은 한 계층의 구성요소가 바로 아래에 있는 것만이 아니라 모든 하위 계층에 접근하는 것을 허용한다.

그러므로
모델에 존재하는 개념적 의존성과 도메인의 여러 부분에 대한 다양한 변화율과 변화의 근원을 검토하라.
AGGREGATE, MODULE과 같은 각 도메인 객체의 책임이 한 계층의 책임 안에서 말끔히 맞아 떨어지도록 모델을 리팩터링하라.

RESPONSIBILITY LAYER는 공장제어나 재무관리처럼 다양한 도메인에서 좋은 효과를 거둘 수 있다.

---

심화예제: 해운 시스템의 계층화

화물 해운 예제의 적용 범위는 MODEL-DRIVEN DESIGN을 만들고 CORE DOMAIN을 정제했다.
하지만 설계가 구체화되고 모든 부분이 어울리게 조율하는데 곤란을 겪고 있어
모든 사람이 이해할 수 있는 대규모 구조를 찾는 중이다.

Figure 16.3. A basic shipping domain model for routing cargoes

Figure 16.4. Using the model to route a cargo during booking

해운 도메인의 개념에서 자연적인 층이 있다는 걸 알게 됐다.
운송수단에 실린 화물을 언급하지 않고 운송일정에 관해 얘기하는 건 문제가 없다.
하지만 화물을 운송하는 운송수단을 언급하지 않고 화물 추적에 관해 얘기하는 건 어렵다.
개념적 의존성은 매우 분명하므로 Operation(운영)과 운영 활동을 조정하는 Capability(기능) 계층으로 구분한다.

"운영" 책임

회사의 일상 활동 대부분은 Cargo 운영 객체가 중심이다.
Route Specification은 Cargo에 필수 불가결한 부분이며 배송 요구사항을 나타낸다.
Itinerary는 운영상의 배송 계획이다.
이 둘은 Cargo의 AGGREGATE를 구성하며, 두 객체의 생명주기는 실제 배송 기간과 결부된다.

"기능" 책임

운영활동을 수행하고자 회사에서 활용하는 자원을 반영한다.
Transit Leg가 그 예이며, 선박 운항 일정에 화물 운반을 위한 용적이 전부 사용되거나 아니거나 한다.

해운 선단을 운영하는데 초점을 맞추면 Transit Leg는 운영 계층이다.

Customer는 까다로운데, 어떤 업무는 고객이 화물이 배송이 되는 동안 일시적으로만 중요하다.
그래서 고객은 화물 운송 서비스에 필요한 운영상의 관심사로 간주한다.
하지만 지금까지의 예제에 나온 해운회사는 고객과의 장기적인 관계 구축을 목표로 하므로 Customer는 잠재 계층에 속한다.
따라서 기술적인 결정에 속하지 않는다.

Cargo와 Customer의 연관관계는 단 방향이므로 Cargo Repository에는 특정 Customer의 Cargo를 찾는 쿼리가 필요하다.
대규모 설계를 도입하면서 이를 하나의 요구사항으로 보는 것이 타당하다.

Figure 16.5. A query replaces a bidirectional association that violates the layering.

Figure 16.6. A first-pass layered model

운영, 기능 계층을 구분해도 질서는 계속해서 발전한다.
Router(항로설정기)를 비롯 다른 구성 요소들은 운영상의 현실이나 계획이 아니다.
팀은 Decision Support를 책임질 새로운 계층을 정의한다.

"의사결정 지원" 책임

이 계층은 사용자에게 계획과 의사결정을 위한 도구를 제공하고, 특정 의사결정을 자동화할 수 있다.

Router는 Cargo를 보내는 최선의 방법을 고르는 데 도움을 주는 SERVICE이다. 그래서 의사결정 책임에 속한다.

Transport Leg의 선호 여부 속성은 회사에서 자체 선박 혹은 회사에 유리한 다른 회사의 선박을 이용하는 걸 선호하는 걸 표현한다.
그래서 이 속성 혜택이 있는 운송수단을 이용하는 쪽으로 Router를 편중한다.
"기능"과 무관한 속성이며 의사결정 방향을 결정하는 정책일 뿐이다.

Figure 16.7. Refactoring the model to conform to the new layering structure

이렇게 분해하면 Transport Leg가 운송 기능이면서 Route Bias Policy(항로 편중 정책)가 명시적으로 드러난다.
도메인에 대한 심층적인 이해해 근거한 대규모 구조는 종종 의미가 명확해지는 방향으로 모델을 나아가게 한다.

이제 새로운 모델은 대규모 구조에 맞게 그려진다.

Figure 16.8. The restructured and refactored model

대규모 구조의 가치는 복잡성이 증가할수록 커진다.

이 구조가 어떻게 진행 중인 설계에 영향을 주는가?

대규모 구조가 만들어지면 후속 모델링과 설게 결정은 대규모 구조를 감안해 이뤄져야 한다.

새로운 기능의 예로 항로 설정 제한을 위험물에 적용하는 것으로 생각해 볼 수 있다.
이 위헝물은 특정 운송 수단에만 실어야 하고 특정 항구에는 내리지 못한다.
이제 Router가 이런 규정을 준수할 수 있게 만들어야 한다.

매력적인 설계로는 이런 항로 설정 규칙을 통합할 책임을 Cargo에 부여하는 것이다.
Cargo에는 Route Sepcification과 위험물 코드를 가지고 있다.

Figure 16.9. A possible design for routing hazardous cargo

Figure 16.10

문제는 이 설계는 대규모 구조와 맞지 않는다.
HazMat Route Policy Servicce에 대해 Cargo의 의존성이 문제가 된다.
프로젝트가 이런 계층에 얽매여 있으면 그대로 두면 안되고, 만약 방치하면 구조가 모델을 따를 것이라 기대한 개발자는 혼란에 빠진다.

HazMat Route Policy Service도 괜찮지만 정책을 사용하는 책임을 옮길 필요가 있다.
정책을 수집할 책임을 Router에 부여한다.
이는 정책이 의존할지도 모를 객체를 포함하게 Router 인터페이스를 변경한다는 뜻이다.

Figure 16.11. A design consistent with layering

Figure 16.12

당장은 이 설계가 최선이라고 할 수는 없다.
하지만 프로젝트에 참여한 사람이 일관된 방식으로 결정을 내린다면 전체적으로 설계는 훨씬 더 이해하기 쉬워지며
그러면 세부 설계에서 적당한 수준의 타협점을 찾을만한 가치는 있다.

구조가 부자연스러운 설계 선택을 강요한다면 EVOLVING ORDER를 유지하고
구조를 평가해 수정하거나 버려야 할 것이다.

적절한 계층의 선택

대규모 구조를 찾을 때는 문제 도메인을 이해하고 실험하는 것이 중요하다.
아무것도 모르는 상태에서 선택할 때 처럼 구조의 변형을 고려할 때도 적용해 볼 지침을 알아본다.

• 스토리텔링, 계층은 도메인의 기본적인 실제 상황과 우선순위를 전해줘야 한다. 기술적 결정보다는 업무 관련 모델링 결정이다. 그래서 업무 우선순위가 드러난다.
• 개념적 의존성, 상위 개념은 하위 계층의 배경을 가져야 하고 하위 계층은 독자적인 의미를 지녀야 한다.
• CONCEPTUAL CONTOUR, 다양한 계층에 놓인 객체가 변화의 원인이 서로 다르면 계층은 객체간의 구획을 짓는 일에 일조한다.

새로운 모델 계층은 항상 다시 시작해야 하는 건 아니다.
공장이나 화물 선박 같은 대규모 고정자본 자산의 활용과 관련된 업무는 물류 소프트웨어를
잠재 기능 계층과 운영 계층으로 구성할 수 있다.

• 잠재 기능, 조직의 자원과 자원을 구성하는 방식이 잠재 기능 계층의 핵심이다. 업체와의 계약도 잠재 기능이다.
• 운영, 스스로의 노력과 활동, 우리가 파는 것을 확인하는 것이다. 잠재 기능 관련 객체는 운영 계층을 참조하지 않는다.

의사결정을 자동화하려는 경우 운영 계층 위에 또 하나의 계층을 구성할 수 있는 책임이 존재한다.

• 의사결정 지원, 분석과 의사 결정을 위한 계층이다. 잠재 기능이나 운영과 같은 하위 계층에서 나온 정보를 분석한 내용을 기반으로 한다.

많은 프로젝트에서 의사결정 지원을 데이터 웨어하우스 기술을 이용해 구현한다.
이 계층은 운영 소프트웨어와 CUSTOMER/SUPPLIER 관계를 맺은 별도의 BOUNDED CONTEXT가 된다.

정교한 업무 규칙이나 법적 요구사항을 강제하는 소프트웨어는 RESPONSIBILITY LAYER를 구성할 수 있다.

• 정책, 규칙과 목표는 수동적이나 다른 계층의 행위를 제약한다. 이런 상호작용을 설계하는 건 미묘한 일일 수 있다.

Figure 16.13. Conceptual dependencies and shearing points in a factory automation system

금융이나 보험 서비스는 주로 잠재 기능을 현재 운영 상태에 따라 결정한다.
새로운 보험 약정의 위험을 감수하는 능력은 보험사의 업무 다각화를 기반으로 한다.
잠재 기능 계층은 운영으로 병합되고 다른 계층화가 발전할 것이다.

여기서 한 가지 영역이 주목을 받는데 고객과 체결한 계약이다.

• 계약(Commitment), 향후 운영 방향을 제시할 목표를 명시한다. 정책과 다른 점은 계약이 진행중인 업무 활동읠 일부이고 변화한다는 점에서 운영의 성격을 가지기도 한다.

Figure 16.14. Conceptual dependencies and shearing points in an investment banking system

잠재 기능과 계약 계층은 서로 배타적이지 않다.
해운 서비스를 하는 운송 회사는 이 두 계층을 모두 사용한다.
상황을 바꾸고 실험해 봐야 한다. 그 와중에도 계층화 시스템은 단순하게 유지해야 한다.
계층이 5개를 넘어가면 다루기 힘들어지고 복잡성의 문제가 새로운 형태로 나타나게 된다.
대규모 구조는 반드시 철저하게 정제되어야 한다.

[jongfeel]

대규모 구조가 진행중인 설계에 어떤 영향을 주는지에 대한 설명에서 다음의 문단이 있다.

They both have pros and cons. But if everyone on a project makes decisions in a consistent way, the design as a whole will be much more comprehensible, and that is worth some modest trade-offs on detailed design choices.

everyone on a project makes decisions in a consistent way
이 문장이 인상적이다. 해석하자면 모두가 일관된 방향으로 프로젝트 결정을 내린다는 뜻으로
그렇게 하면 설계가 이해할 수 있고 세부 설계 결정의 트레이드 오프가 가치가 있다고 설명한다.

일관된 방향의 전체적인 설계는 중요하면서도 어렵다.
한명이 주도적으로 하는 설계는 속도를 내는데 부하가 있고
전체적인 설계 방향이 없이 각자가 속도를 내면 일관성이 없어진다.

그래서 모두가 일관성 있는 결정을 할 수 있다는 건 좋은 프로젝트 팀일 때 가능하다고 본다.