> For the complete documentation index, see [llms.txt](https://jihunparkme.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jihunparkme.gitbook.io/docs/book/oee/06.md).

# 06.객체 지도

## 기능 설계 대 구조 설계

* `기능 분해 방법`의 경우 시스템 기능은 더 작은 기능으로 분해되고 각 기능은 서로 밀접하게 관련된 하나의 덩어리를 이루기 때문에 기능이 변경될 경우 기능의 축을 따라 설계된 소프트웨어가 전체적으로 요동치게 된다.
* `객체지향 접근방법`은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.*객체의 구조에 집중하고 기능이 객체의 구조를 따르게 만든다*. 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.

## 두 가지 재료: 기능과 구조

* 객체지향 세계를 구축하기 위해서는 사용자에게 제공할 `기능`과 기능을 담은 안정적인 `구조`라는 재료가 준비되어 있어야 한다.
  * `기능` : 사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스
  * `구조` : 시스템의 기능을 구현하기 위한 기반, 기능 변경을 수용할 수 있도록 안정적이어야 함
* 기능과 구조를 표현하기 위해 일관되게 적용할 수 있는 기법
  * `기능`은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
  * `구조`는 사용자나 이해관계자들이 도메인에 관해 생각하는 개념과 개념들 간의 관계로 표현
* `기능`을 수집하고 표현하기 위한 기법을 `유스케이스 모델링`
* `구조`를 수집하고 표현하기 위한 기법을 `도메인 모델링`

## 안정적인 재료: 구조

**도메인 모델**

* 사용자가 프로그램을 사용하는 대상 분야를 `도메인`
* 도메인 모델은 이해관계자들이 바라보는 멘탈 모델(Mental Model)이다.
  * 멘탈 모델이란 자기 자신, 다른 사람, 환경, 자신이 상호작용하는 사물들에 대해 갖는 모형
* 도메인 모델은 도메인에 대한
  * 사용자 모델(사용자가 제품에 대해 가지고 있는 개념들의 모습)
  * 디자인 모델(설계자가 마음 속에 갖고 있는 시스템에 대한 개념화)
  * 시스템 이미지(최종 제품)
  * 를 포괄하도록 추상화한 소프트웨어 모델이다.
* 도메인 모델은 소프트웨어에 대한 멘탈 모델이다.

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

* 도메인 모델이란 사용자들이 도메인을 바라보는 관점이며, 설계자가 시스템의 구조를 바라보는 관점인 동시에 소프트웨어 안에 구현된 코드의 모습 그 자체
* 객체지향 패러다임은 사용자의 관점, 설계자의 관점, 코드의 모습을 모두 유사한 형태로 유지할 수 있게 하는 유용한 사고 도구와 프로그래밍 기법을 제공
* 위 특징을 `연결완전성` 또는 `표현적 차이`라고 한다.

**표현적 차이**

* 소프트웨어 객체가 현실 객체를 왜곡한다고 하더라도 소프트웨어 객체는 현실 객체의 특성을 토대로 구축된다.
* 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 `표현적 차이` 또는 `의미적 차이` 라고 한다.
* 소프트웨어 객체는 도메인 모델을 통해 표현되는 도메인 객체들을 `은유`해야 한다.

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

* 도메인 모델이 제공하는 구조가 상대적으로 안정적이다.
* 사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 *사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.*
* 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어의 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수 있다.!

## 불안정한 재료: 기능

**유스케이스**

* `기능적 요구사항`이란 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것.
* 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 `유스케이스`
* "사용자 목표가 유스케이스의 핵심이다. 유스케이스는 공통의 사용자 목표를 통해 강하게 연관된 시나리오의 집합이다"

**유스케이스의 특성**

1. "유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'다"
   * 유스케이스의 핵심은 사용자와 시스템 간의 상호작용을 일련의 이야기 흐름으로 표현하는 것
2. "유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다."
   * 시나리오는 유스케이스를 통해 시스템을 사용하는 하나의 특정한 이야기 또는 경로다.
   * 시나리오를 유스케이스 인스턴스라고도 한다.
3. 유스케이스는 단순히 피처(feature) 목록과 다르다.
   * 피처는 시스템이 수행해야 하는 기능의 목록을 단순하게 나열한 것
4. 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지말아야 한다.
   * 본질적인 유스케이스라고도 한다.
5. 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.
   * 유스케이스에서 객체 설계로의 전환은 경험과 상식과 의사소통을 기반으로 한 창조 작업이다.

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

* 유스케이스에는 단지 사용자가 시스템을 통해 `무엇을 얻을 수 있고` `어떻게 상호작용할 수 있느냐`에 관한 정보만 기술
* 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐

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

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

* 변경에 유연한 소프트웨어를 만들기 위해서는 `유스케이스에 정리된 시스템의 기능`을 `도메인 모델을 기반으로 한 객체들의 책임`으로 분배해야 한다.
* 사용자에게 시스템이 수행하기로 약속한 기능은 결국 시스템의 책임으로 볼 수 있다.
* 시스템에 할당된 커다란 책임은 이제 시스템 안의 작은 규모의 객체들이 수행하야 하는 더 작은 규모의 책임으로 세분화된다.
* 이제 우리는 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 한다.
  * 협력을 완성하는 데 필요한 메시지를 식별하면서 객체들에게 책임을 할당해 나간다.
* 협력에 참여하는 객체를 구현하기 위해 클래스를 추가하고 속성과 함께 메서드를 구현하면 시스템의 기능이 완성!
* 객체 설계는 가끔(?) 아래와 같이 표현

```
요구사항들을 식별하고 도메인 모델을 생성한 후,
소프트웨어 클래스에 메서드들을 추가하고,
요구사항을 충족시키기 위해 객체들 간의 메시지 전송을 정의하라.
```

* `유스케이스`는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공
* `도메인 모델`은 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공
* `책임-주도 설계`는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조

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

* 도메인 모델을 기반으로 객체 구조를 설계하는 이유는 도메인 모델이 안정적이기 때문
* 비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지
  * 기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응 관계만 수정될 뿐.