Ch.6 객체지도

안정적인 구조를 기반으로 시스템을 분할하는 객체지향적인 접근법은 역할, 책임, 협력을 기반으로 시스템의 기능을 구현하는 책임-주도 설계의 본질을 이해하는 것에 도움이 된다.

자주 변경되는 기능이 아닌 구조를 따라 역할, 책임, 협력을 구성하라.

---

기능 설계 대 구조 설계

불행하게도 요구사항은 변경된다.

설계라는 행위를 중요하게 만드는 것은 변경에 대한 필요성이다.
(성능 보단 유지보수를 생각하라는 말이 사실인것 같다.)

우리는 변경을 예지하는 것이 아닌 변경을 수용할 수 있는 선택의 여지의 설계를 마련해 놓는 것이다.

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

객체지향은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.

---

두가지 재료 : 기능과 구조

'구조'는 클라이언트가 도메인에 관해 생각하는 개념을 표현
'기능'은 클라이언트의 목표를 만족시키기 위해 책임을 수행하는 행위

기능을 수집하고 표현하기 위한 기법 => '유스케이스 모델링'
구조를 수집하고 표현하기 위한 기번 => '도메인 모델링'

안정적인 재료 : 구조

도메인 모델

사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태

쉽게 말해, 프로그램을 사용하는 대상 분야가 된다. (ex. 게임, 은행, 쇼핑...)

소프트웨어 객체는 은유를 기반으로 재창조된 것이기에 현실 객체가 갖지 못한 특성을 가질 수도 있고 현실 객체가 하지 못하는 행동을 할 수도 있다.

소프트웨어 객체는 대상이 현실적인지, 현실적이지 않은지에 상관없이 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

위에서 표현한 '은유'는 현실에 사용자가 도메인에 대해 생각하는 '개념'들을 투영해 만들어야 된다.

도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계한다는 것이다.

사용자만이 도메인의 본질적인 측면을 잘 이해하고 있기 때문이다.
(우리가 은행앱을 sns로 사용하지 않는 것과 같이 은행앱은 우리에게 은행업무를 편하게 봐주는 기능을 제공해주면 끝이다.)

도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 해도 실제로 사용자에게 중요한 것은 도메인이 아닌 '기능'
즉, 사용자에게 원하는 목표를 달성할 수 있는 다양한 기능을 제공하기 위해 객체지향에서는 '유스케이스'라는 기법이 있다.

---

불안정한 재료 : 기능

유스케이스

책에선 정기예금 도메인에서 예금주가 정기예금을 중도 해지할 경우 예금주에게 지급될 이자를 계산하는 기능을 보여준다.

- 예금주가 정기예금 계좌를 선택
- Server는 정기예금 계좌정보를 보여준다.
- 예금주는 금일 기준으로 예금을 해지할 경우 지급받는 이자를 요청
- Server는 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공 (핵심 기능)

확장성 고려 : 사용자는 해지 일자를 다른 일자로 입력 가능

유스케이스의 특징

1. 사용자와 시스템 간의 상호작용 '텍스트'

   • 중요한 것은 사용자와 시스템 간의 상호작용을 흐름으로 표현하는 것
     

2. 하나의 시나리오가 아닌 여러 시나리오들의 집합

   • 확장성 까지 생각하며 예금주의 목표와 관련된 모든 시나리오를 생각하자
     

3. 단순히 필요한 기능의 목록이 아니다.

   • 기능을 나열하는 것이 아닌 시나리오를 통해 연관된 기능을 함께 묶을 수 있다.
     

4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 않는다.

   • 기본적인 사항아닐까 싶다. 전달하는 파라미터에 굳이 예금자의 정보를 넣을 필요없이 해지일자만을 넘겨주는 것이 올바르다.
     

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

   • 소프트웨어 객체간 결합도와 캡슐화를 생각하라는 의미 아닐까.
     좀더 자세한 내용을 후술 한다.
     

유스케이스는 설계, 객체지향 기법이 아니다.
시스템이 외부에 제공해야 하는 행위만 포함하기에 시스템의 내부 구조를 유추할 수 있는 방법은 존재하지 않는다.
(어디서 많이 들어본 얘기다. 지금껏 객체지향을 공부하며 자율적인 객체에 대한 내용이 아닌가.)

하지만 책에서는 유스케이스는 단지 기능적 요구사항을 정리한 기법이라고 표현한다.

객체 != 유스케이스

정리해보자면

유스케이스를 통해 정리된 시나리오 => 객체로 '아름답게' 변환해야 하는것 

이 되는 것같다.

---

느낀점

• 도메인 설계에 관해 어떤 글 보다도 아주 깔끔하게 설명한 챕터가 아닐까 싶다.
• "책임-주도 설계의 대척점에 있는 도메인 주도 설계!" 라고 생각 하고 있었다. 책을 읽고 변화된 생각은
  "도메인 주도 설계를 감싸고 있는 책임-주도 설계"로 바뀐 것 같다.
• 매번 디자인패턴에 따라서만 관습적으로 도메인을 설계해 본 것 같다.
  다음부턴 이번장을 참고하여 도메인모델을 생각하여 구조를 파악하고 기능을 고려하여 유스케이스를 작성해보고 객체를 설계해보며 만들어 보고 싶다.