객체 지도

자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라

---

기능 설계 대 구조 설계

• 기능 측면의 설계
  • 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다.
  • 기능을 중심으로 설계한 후 구조가 기능에 따르게 한다
  • 소프트웨어 개발의 충분조건
  • 초기 단계의 핵심. 사람들이 필요한 것을 만들어야 한다.
• 구조 측면의 설계
  • 제품의 형태가 어떠해야 하는지에 초첨을 맞춘다.
  • 소프트웨어 개발의 필요조건
  • 변화하는 요구사항을 쉽게 반영할 수 있는 기반
  • 시스템 기능을 객체 간의 책임으로 분배 ➡️ 기능이 변경되더라도 객체가 변경되지 구조는 그대로 유지된다

설계를 할 때에 두 가지 측면을 함께 녹여 조화를 이뤄야 한다.

p. 182
좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다. 설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며, 설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

---

두 가지 재료: 기능과 구조

• 기능: 사용자의 목표 만족을 위해 책임을 수행하는 시스템의 행위 ➡️ 유스케이스 모델링
• 구조: 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계 ➡️ 도메인 모델링

---

안정적인 재료: 구조

도메인 모델

• 도메인: 사용자가 프로그램을 사용하는 대상 분야
• 모델: 대상을 단순화, 추상화하여 표현한 것
• 도메인 모델: 소프트웨어 개발과 관련된 이해관계자들이 도메인을 생각하는 관점

사람마다 프로그램이 제공하는 분야에 대해 규칙, 개념, 관계 등 생각하는 바가 있다. 이해관계자들 각각의 멘탈 모델과 사용자가 제품에 가지고 있는 멘탈 모델이 일치해야 한다.

---

객체지향

소프트웨어는 사용자가 제품을 바라보는 관점을 반영해야 한다. 즉 애플리케이션이 도메인 모델을 기반으로 설계되어야 한다. 객체지향은 이런 요구사항을 가장 범용적으로 만족시킬 수 있는 패러다임이다.

사용자의 도메인에 대한 관점 = 설계자의 시스템 구조에 대한 관점 = 구현된 코드

---

도메인 모델을 기반으로 해야하는 이유

1. 표현적 차이

• 표현적 차이란? 소프트웨어 객체와 현실 객체 사이의 의미적 거리
• 은유를 통해 표현적 차이를 줄이는 것이 중요하다.
  • 실제와 객체사이의 간극을 줄일수 없다.
  • 실제로 반영해야 하는 것은 사용자의 도메인 모델이다.
  • ➡️ 도메인 모델을 은유로 표현해야 한다.

2. 구조의 안정성

• 본질을 반영해야 변경될 확률이 적고 쉽게 대처할 수 있다.
• 그리고 본질을 표현한 것이 도메인 모델이므로 도메인 모델이 기능을 담을 수 있는 안정적인 구조를 제공할 수 있다.

---

불안정한 재료: 기능

유스케이스

• 유스케이스
  • 사용자는 자신의 목표를 달성하기 위해 시스템과의 상호작용을 하며 이런 흐름을 정리한 것
  • 사용자 목표(요청)와 관계있는 시나리오의 집합
• 일차 액터(primary actor): 유스케이스를 시작하는 액터

---

유스케이스의 특성

1. 사용자와 시스템 간의 상호작용을 이야기 흐름으로 표현한 ‘텍스트’이다.
2. 하나의 시나리오가 아니라 여러 시나리오의 집합이다.
3. 단순한 피처 목록이 아니다.
   • 수행하는 기능(피처)을 묶어서 시스템 기능에 대한 문맥을 만든다.
4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
   • 시스템 행위에 초점을 맞춘다.
5. 내부 설계와 관련된 정보를 포함하지 않는다.
   • 유스케이스는 시스템을 통해 얻을 수 있는 것, 상호작용하는 방법만 기술한다.
   • 유스케이스는 도메인 모델에 포함될 수 있는 개념, 속성에 대한 정보를 제공한다
   • 이를 구축할 구조는 없다

---

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

p. 197
도메인 모델은 안정적인 구조를 개념화하기 위해,
유스케이스는 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구다.

 

객체 설계

• 유스케이스에서 각 객체가 가지는 책임
  • 프로그래머: 사용자로부터 전송된 메세지를 시스템이 수행하도록 하는 책임
  • 시스템: 사용자와 만나는 경계에서 사용자와 협력하여 목표를 만족시키는 책임
  • 객체: 시스템이 가진 커다란 책임을 세분화한 작은 규모의 책임
• ➡️ 설계 과정
  1. 요구사항들을 식별
  2. 도메인 모델 생성
  3. 소프트웨어 클래스에 메서드 추가
  4. 객체들 간의 메시지 전송 정의

---

통합하기

• 유스케이스: 첫 번째 메시지와 사용자가 달성하려는 목표 제공
• 도메인 모델: 안정적 구조 제공
  • 객체 이름: 도메인 모델에 포함된 개념에서 차용
  • 책임
    • 도메인 모델에 정의한 개념
    • 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당

---

정리

- 사용자가 실제 사물을 바라보는 관점을 소프트웨어의 객체에 반영해야 한다.
- 이런 관점이 도메인 모델이며, 이것을 기반으로 구조를 설계해야 한다.
- 기능적 요구는 사용자의 목표를 반영한다.
- 목표를 달성하기 위한 시나리오가 유스케이스이다.
- 도메인 모델과 유스케이스를 통해 설계할 때 변경에 유연한 설계를 할 수 있다.