06장. 객체 지도

유일하게 변하지 않는 것은 모든 것이 변한다는 사실뿐이다.

• 헤라클레이토스(Heraclitus of Ephesus)

• 기능적이고 해결책 지향적인 접근법
• 구조적이고 문제 지향적인 접근법

기능이 아닌 구조를 기반으로 모델을 구축하는 편이 범용적이고 이해하기 쉬우며 변경에 안정적이다.

기능 설계 대 구조 설계

소프트웨어에는 두가지 측면이 존재한다.

• 기능
• 구조

기능은 제품이 사용자를 위해 무엇을 할 수 있는가
구현은 제품의 형태가 어떠해야하는지 에 대해

이 두가지 측면을 모두 만족시키는 것이 좋다..

훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분조건이라면 훌륭한 구조는 훌륭한 소프트웨어를 만들기 위한 필요조건이다.

좋은 소프트웨어는 공통적으로 훌륭한 기능을 제공하면서 새로운 기능을 빠르고 안정적으로 추가할 수 있다는 점이다.

그래서 깔끔하고 단순하며 유지보수하기 쉬운 구조는 새로운 요구사항을 반영할 수 있도록 하는 기반이 된다.

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.

언젠가 변경은 무조건적으로 일어나고 이에 대해 수용할 수 있도록!! 설계를 하는 것이 중요하다.

전통적인 기능 분해는 자주 변경되는 기능을 중심으로 설계 후 구조가 기능에 따르게 한다.

• 이게 변경에 취약한 이유다.
  이 경우 시스템 기능은 더 작은 기능으로 분해되고 서로 밀접하게 관련된 하나의 덩어리가 된다.

객체 지향은 자주 변경되지 않는 객체 구조를 바탕으로 객체 간 책임으로 분배하다.
이러면 기능이 변경되더라도 객체 간 구조는 그대로 유지된다.

객체 지도는 빠르게 변화하는 기능을 수용할 수 있는 자리를 제공한다.
안정적이며 재사용가능하면서도 범용적이다.

두가지 재료: 기능과 구조

객체지향 구조를 구축하기 위해서는

• 사용자에게 제공할 기능
• 기능을 담을 안정적인 구조
  가 필요하다.

초점은 이 두가지를 어디서 구하냐가 된다.

• 구조는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현하다.
• 기능은 사용자의 목표를 만족시키기 위해 책임을 수해아는 시스템의 행위로 표현한다.

일반적으로 기능을 수집하고 표현하기 위한 기법을 유스케이스 모델링
구조를 수집하고 표현하기 위한 기법을 도메인 모델링

이라 한다

이 두 가지 결과물을 각각 유스케이스, 도메인 모델 이라고 한다.

안정적인 재료: 구조

도메인 모델

사용자가 프로그램을 사용하는 대상 분야를 도메인이라 한다.

도메인 모델에서 모델이란 대상은 단순화해 표현한 것이다.
모델은 지식을 선택적으로 단순화해 의식적으로 구조화한 형태다.

모델은 대상을 추상화하고 단순화한 것이다.

이는 세부사항을 무시해 복잡성을 관리할 수 있도록 도와준다.

도메인과 모델을 연결하면

도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.

그니까 소프트웨어가 목적하는 영역 내 개념과 관계, 규칙, 제약등을 추상화한 것이다.

이는 단순한 다이어그램이 아니라
이해관계자들이 바라보는 멘탈 모델이다.

• 멘탈 모델은 자기자신, 다른사람, 환경 등 다신이 상호작용하는 사물들에 갖는 모형이다.

사용자들은 도메인 현상을 이해하고 반응하기 위해 도메인과 관련된 멘탈 모델을 형성한다.

이 멘탈 모델과 제품의 모든것이 일치해야한다.

도메인의 모습을 담을 수 있는 객체지향

최종 제품은 사용자의 관점을 반영해야 한다는 것.

최종 코드는 사용자가 도메인을 바라보는 관점을 반영해야한다.

• 이건 애플리케이션이 도메인 모델을 기반으로 설계돼야 한다는 것을 의미한다.

객체지향을 사용하면 사용자들이 이해하는 도메인 구조와 유사하게 코드를 구조화할 수 있다.
또 사람들이 만지고 느끼고 볼 수 있는 실체를 시스템 안 객체로 재창조할 수 있게 해준다.

동적인 객체가 가진 복잡성을 정적 타입으로 단순화, 클래스르르 이용해 타입을 코드 안으로

객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지 모두 유사한 모습으로 유지하도록 하는 것이 간능하다.
이를 연결완전성, 표현적 차이라 한다.

표현적 차이

소프트웨어 객체와 현실 객체 사이의 의미적 거리를 표현적 차이 또는 의미적 차이라 한다.
핵심은 이 차이를 최대한 줄이는 것이다.

그치만 대부분 현실엔 존재하지 않는 것들이다.

그래서 소프트웨어 객체를 만들기 위해 은유해야 하는 대상은 도메인 모델이다.

불안정한 기능을 담는 안정적인 도메인 모델

도메인 모델이 제공하는 구조는 상대적으로 안정적이다.

도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점으로 설계하고 구현하는 건데
사용자들은 도메인의 본질적인 측면을 잘 알고 있기 때문인다.

본질적이라는 것은 변경이 적고 그 특성이 오랜 시간 유지된다는 것이다.
그래서 이를 바탕으로 만들면 변경에 쉽게 대처하는 것이 쉬워진다.

안정적인 구조를 제공하는 도메인 모델을 기반으로 구조를 설계하면
변경에 유연하게 대응 가능한 소프트웨어를 만들 수 있다.

불안정한 재료: 기능

유스케이스

기능적 요구사항이란 시스템이 사용자에게 제공해야 하는 기능의 목록이다.

사용자는 자신의 목표를 달성하기 위해 시스템과 상호작용한다.

사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 유스케이스라 한다.

유스케이스의 가치는 사용자들의 목표를 중심으로 기능적인 요구사항들을 이야기 형식으로 묶을수 있다는 것이다.

흩어진 기능들을 사용자 목표로 각 기능이 관계를 지닌 체계를 이룰수 있게 해준다.

"사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다."

유스케이스의 특성

1. 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 텍스트다.

유스케이스는 다이어그램이 아니다.
중요한 건 상호작용의 흐름.

상호작용을 일련의 이야기 흐름으로 표현하는 것이다.

2. 유스케이스는 하나의 시나리오가 아닌 여러 시나리오의 집합이다.

시나리오는 유스케이스를 통해 사용자가 사용하는 하나의 특정한 이야기 혹는 경로다.

시나리오를 유스케이스 인스턴스라고도 한다.

3. 유스케이스는 단순한 피처 목록과는 다르다.

피처는 시스템이 수행해야하는 기능의 목록이다.

피처의 단점은 여러 피처를 서로 연관이 없는 독립적인 기능으로 보이게끔 하는 것이다.

여러 피처를 포함하는 이야기로 묶는 것이 유스케이스의 장점이다.

4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야한다.

유스케이스는 자주 변경되는 사용자 인터페이스 요소는 배제하고 사용자 관점에서 행위에 초점을 맞춘다.
이런 배제한 형식을 본질적인 유스케이스라 한다.

5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.

유스케이스의 목표는 시스템 기능을 이야기 형식으로 묶는 것이지 내부 설계를 설명하는 것이 아닌다.

유스케이스는 설계 기법도, 객체지향 기법도 아니다.

유스케이스가 단지 사용자가 바라보는 외부 관점만을 표현한다는 점에서
내부 구조나 실행 메커니즘 등 어느 정보도 제공하지 않는다.

유스케이스는 외부에 제공해야하는 행위만 포함하기 때문에 내부 구조를 알 수 있는 방법은 없다.

이는 객체지향이 아닌 다른 패러다임에도 적용가능하다.

유스케이스는 단지 기능적 요구상항을 사용자의 목표를 중심으로 묶기 위한 정리 기법이다.

재료 합치기: 기능과 구조의 통합

도메인 모델, 유스케이스, 그리고 책임 주도 설계

변경에 유현한 소프트웨어를 만들기 위해서 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야한다.

객체지향은 모든 것이 객체라는 것에서 시작한다.

• 시스템을 사용자로부터 전송된 메시지를 수행하기 위해 책임을 수행하는 거대한 자율적인 객체.

시스템 객체 안에는 여러 객체가 있을 수 있는데
커다란 책임을 더 작은 크기의 객체들의 협력을 통해 구현한다.

시스템에 할당괸 커다란 책임을 어떻게 저 작은 규모의 책임으로 세분화해 어떤 객체를 선택할 것인가?

여기서 도메인 모델이 사용된다.

• 도메인 모델에 포함된 개념을 은유하는 객체를 선택해야한다.

차례대로 보면

유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보고 안정적인 구조에 책임을 분배할 수 있도록 해준다.

도메인 모델은 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공한다.

책임 주도 설계는 유스케이스로 부터 첫번째 메시지와 목표, 기능을 수행할 수 있는 구조를 받아 객체들간 협력 공동체를 만든다.

• 각 객체는 자신의 책임을 수행하기 위해 다른 객체에게 책임을 요청

• 객체의 이름은 도메인 모델에 개념에서 차용

• 책임은 도메인 모델에 정의한 개념에서 차용

유스케이스에서 출발해 객체들의 협력으로 이어지는 흐름은 객체 안 객체를 포함하는 재귀적 합성이라는 개념을 보여준다.

기능 변경을 흡수하는 안정적인 구조

• 도메인 모델을 구성하는 개념은 비지니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
• 도메인 모델을 구성하는 개념 간의 관계는 규칙을 기반으로 하기 때문에 비지니스 정책이 변경되지 않는 한 안정적으로 유지 된다.

이런 도메인 모델의 특성이 있어
도메인 모델을 중심으로 구조 설계 유스케이스 기능을 책임으로 분배하는 게 유연함을 보장해준다.

기능 요구사항이 변경되면 객체 간 대응 관계만 수정된다.
이로 변경에 대한 파급효과를 최소화하고 변경에 유연하게 대응할 수 있게 된다.

객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 방법이 동일하다는 점이다.

또한 이의 역방향도 가능하다.

그니까 코드의 변경으로 도메인 모델의 변경 사항을 유추할 수 있다.

코드에서 모델로 흐름을 가역성이라 한다.

사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표다.