객체 지도

유일하게 변하지 않는 것은 '모든 것이 변한다'는 사실뿐이다. -헤라클레이토스

프로그래밍에 종사하는 사람들은 프로그래밍 도메인을 커피를 입력으로 코드를 출력하는 함수로 파악한다.

사람들은 길을 모를 때 2가지 방법중 하나를 이용해 길을 찾는다.

기능적이고 해결책 지향적인 접근법(Functional, solution0directed approach)

다른 사람에게 길을 물어보는 방법

현재의 마을에서 다른 마을로 이동하는 현재의 요구만을 만족시킬 수 있다.

기능에 구조를 종속시키는 방법

구조적이고 문제 지향적인 접근법(structural, problem-directed approach)

지도를 이용하는 방법

지도는 현재의 목적뿐만 아니라 다양한 목적을 위해 재사용될 수 있다.

지도는 재사용될 수 있다. 즉 범용적이다.

지도가 범용적인 이유는 지도를 사용하려는 사람들이 원하는 '기능'에 비해 지도에 표시된 '구조'가 더 안정적이기 때문이다.

구조에 기능을 종속시키는 방법

기능 설계 대 구조 설계

기능 측면의 설계

사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다.

구조 측면의 설계

제품의 형태가 어떠해야 하는지에 초점을 맞춘다.

설계의 가장 큰 도전은 기능과 구조라는 두가지 측면을 함께 녹여 조화를 이루도록 만드는 것이다.

설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며, 설계의 일차적인 목표는 변경에 소요되는 비용을 낮추는 것이다.

변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능ㅇ이 아닌 안정적인 구조를 중심으로 설계하는 방법이다.

두가지 재료: 기능과 구조

기능

사용자가 자신의 목표를 달성하기 위해 사용할 수 있는 시스템의 서비스

사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현한다.

구조

시스템의 기능을 구현하기 위한 기반으로 기능 변경을 수용할 수 있도록 안정적이어야 한다.

사용자나 이해관계들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계를 표현한다.

유스케이스 모델링

기능을 수집하고 표현하기 위한 기법

도메인 모델링

구조를 수집하고 표현하기 위한 기법

두 가지 모델링 활동의 결과물을 각각 유스케이스와 도메인 모델 이라고 한다.

안정적인 재료: 구조

도메인 모델

도메인

사용자가 프로그램을 사용하는 대상 분야

도메인 모델

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

도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지를 포괄하도록 추상화한 소프트웨어 모델이다.

소프트웨어에 대한 멘탈 모델이다.

소프트웨어 안에 구현된 코드의 모습 그 차제

제품을 설계할 때 제품에 관한 모든 것이 사용자들이 제품에 대해 가지고 있는 멘탈 모델과 정확하게 일치해야 한다. -도널드 노먼(Donald Norman)

멘탈 모델

사용자 모델, 디자인 모델, 시스템 이미지 세 가지로 구분한다.

사용자 모델

사용자가 제품에 대해 가지고 있는 개념들의 모습

디자인 모델

설계자가 마음 속에 갖고 있는 시스템에 대한 개념화

시스템 이미지

최종 제품

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

최종 제품은 사용자의 관점을 반영해야 한다. -도널드 노먼(Donald Norman)

객체지향은 사람들이 만지고 느끼고 볼 수 있는 실체를 시스템 안의 객체로 재창조할 수 있게 해준다.

연결완전성 또는 표현적 차이

객체지향을 이용하면 도메인에 대한 사용자 모델, 디자인 모델, 시스템 이미지 모두가 유사한 모습을 유지하도록 만드는 것이 가능하다.

표현적 차이

소프트웨어 객체와 현실 객체 사이의 관계를 가장 효과적으로 표현할 수 있는 단어는 바로 은유다.

소프트웨어 객체는 현실 객체를 모방한 것이 아니라 은유를 기반으로 재창조한 것이다.

소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델 이다.

도메인 모델을 기반으로 설계하고 구현하는 것은 사용자가 도메인을 바라보는 관점을 그대로 코드에 반영할 수 있게 한다. 결과적으로 표현적 차이는 줄어들 것이다.

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

도메인에 대한 사용자의 관점을 반영해야 하는 이뉴는 사용자들이 누구보다도 도메인의 본질적인 측면을 가장 잘 이해하고 있기 때문이다.

본질적이라는 것은 변경이 적고 비교적 그 특성이 오랜 시간 유지된다는 것을 의미한다.

불안정한 재료: 기능

유스케이스

목표를 가진 사용자와 사용자의 목표를 만족시키기 위해 일련의 절차를 수행하는 시스템 간의 상호작용 관점에서 시스템을 바라봐야 한다.

사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것

산발적으로 흩어져 있는 기능에 사용자 목표라는 문맥을 제공함으로써 각 기능이 유기적인 관계를 지닌 체계를 이룰 수 있게 한다.

유스케이스의 특성

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

2. 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다. 시나리오를 유스케이스 인스턴스라고 한다.

3. 유스케이스는 단순한 피처 목록과 다르다. 단순히 기능을 나열하는 것이 아니라 이야기를 통해 연관된 기능들을 함께 묶을 수 있다는 점

4. 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다. 시스템의 행위에 초점을 맞춘다. 이러한 것을 본질적인 유스케이스 라고 한다.

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

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

유스케이스에는 단지 사용자가 시스템을 통해 무엇을 얻을 수 있고 어떻게 상호작용할 수 있느냐에 관한 정보만 기술된다.

유스케이스는 객체지향과 상관이 없다.

단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐이다.

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

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

책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 강조한다.

책임-주도 설계

시스템의 기능을 역할과 책임을 수행하는 객체들의 협력 관계로 바라보게 함으로써 두 가지 기본 재료인 유스케이스와 도메인 모델을 통합한다.

유스케이스에서 기능이라는 단어를 머릿속에서 책임이라는 단어로 대체한다.

'종도 해지 이자액을 계산하라'라는 메시지를 받는 거대한 객체라고 가정한다.

객체의 이름

도메인 모델에 포함된 개념으로부터 차용하고, 책임은 도메인 모델에 정의한 개념의 정의에 부합하도록 할당한다.

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

도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.

연결완전성

객체지향의 가장 큰 장점은 도메인을 모델링하기 위한 기법과 도메인을 프로그래밍하기 위해 사용하는 기법이 동일하다는 점이다. 도메인 모델링에서 사용한 객체와 개념을 프로그래밍 설계에서의 객체와 클래스로 매끄럽게 변환할 수 있다.

가역성

코드에서 모델로의 매끄러운 흐름을 의미

도메인 모델은 무서나 다이어그램이 아니다.

도메인 모델은 사람들의 머릿속에 들어있는 공유된 멘탈 모델이다.

안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라.