[Book] 객체지향의 사실과 오해 - 6장. 객체 지도

객체 지도

• 지도는 실세계의 지형을 기반으로 만들어진 추상화된 모델
• 지도 은유의 핵심은 기능이 아니라 구조를 기반으로 모델을 구축하는 편이 좀 더 범용적이고 이해하기 쉬우며 변경에 안정적이라는 것이다.
• 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라

기능 설계 대 구조 설계

• 모든 소프트웨어 제품의 설계에는 두 가지 측면이 존해한다.
• 하나는 기능(function) 측면의 설계이고 다른 하나는 구조(structure) 측면의 설계이다.
• 기능 측면의 설계는 제품이 사용자를 위해 무엇을 할 수 있는지에 초점을 맞춘다.
• 구조 측면의 설계는 제품의 형태가 어떠해야 하는지에 초점을 맞춘다.
• 좋은 설계는 나중에라도 변경할 수 있는 여지를 남겨 놓는 설계다.
• 지도 은유를 통해 살펴본 것처럼 변경에 대비하고 변경의 여지를 남겨 놓는 가장 좋은 방법은 자주 변경되는 기능이 아닌 안정적인 구조를 중심으로 설계하는 것
• 객체지향 접근방법은 자주 변경되지 않는 안정적인 객체 구조를 바탕으로 시스템 기능을 객체 간의 책임으로 분배한다.
• 시스템 기능은 더 작은 책임으로 분할되고 적절한 객체에게 분배되기 때문에 기능이 변경되더라도 객체 간의 구조는 그대로 유지된다.
• 이것이 객체를 기반으로 책임과 역할을 식별하고 메시지를 기반으로 객체들의 협력 관계를 구축하는 이유다.
• 안정적인 객체 구조는 변경을 수용할 수 있는 유연한 소프트웨어를 만들 수 있는 기반을 제공한다.

두 가지 재료: 기능과 구조

• 구조는 사용자나 이해관계자들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계로 표현
• 기능은 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
• 기능을 수집하고 표현하기 위한 기법: 유스케이스 모델링
• 구조를 수집하고 표현하기 위한 기법: 도메인 모델링

안정적인 재료: 구조

도메인 모델

• 소프트웨어를 사용하는 사람들은 자신이 관심을 가지고 있는 특정한 분야의 문제를 해결하기 위해 소프트웨어를 사용한다.
• 이처럼 사용자가 프로그램을 사용하는 대상 분야를 도메인이라고 한다.
• 모델이란 대상을 단순화해서 표현한 것이다.
• 도메인 모델이란 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 선택적으로 단순화하고 의식적으로 구조화한 형태다.
• 도메인 모델은 소프트웨어가 목적하는 영역 내의 개념과 개념 간의 관계, 다양한 규칙이나 제약 등을 주의깊게 추상화한 것이다.
• 은행 업무에 종사하는 사람들은 은행 도메인을 고객과 계좌 사이의 돈의 흐름으로 이해할 것이다.
• 중고 자동차 판매상은 구매되는 자동차와 판매되는 자동차의 교환으로 자동차 도메인을 바라볼 것이다.

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

• 도메인 모델이란 사용자들이 도메인을 바라보는 관점이며, 설계자가 시스템의 구조를 바라보는 관점인 동시에 소프트웨어 안에 구현된 코드의 모습 그 자체이다.
• 객체지향을 사용하면 사용자들이 이해하고 있는 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있다.

표현적 차이

• 소프트웨어 객체는 현실 개체에 대한 추상화가 아니다.
• 소프트웨어 객체는 현실 객체를 모방한 것이 아니라 은유를 기반으로 재창조한 것이다.
• 이처럼 소프트웨어 객체와 현실 객체 사이의 의미적 거리를 가리켜 '표현적 차이' 또는 '의미적 차이'라고 한다.
• 소프트웨어 객체를 창조하기 위해 우리가 은유해야 하는 대상은 바로 도메인 모델이다.
• 코드의 구조가 도메인의 구조를 반영하기 때문에 도메인을 이해하면 코드를 이해하기가 훨씬 수월해진다.

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

• 도메인 모델을 기반으로 코드를 작성하는 두번째 이유는 도메인 모델이 제공하는 구조가 상대적으로 안정적이기 때문
• 도메인 모델의 핵심은 사용자가 도메인을 바라보는 관점을 반영해 소프트웨어를 설계하고 구현하는 것
• 사용자 모델에 포함된 개념과 규칙은 비교적 변경될 확률이 적기 때문에 사용자 모델을 기반으로 설계와 코드를 만들면 변경에 쉽게 대처할 수 있을 가능성이 커진다.
• 결론적으로 안정적인 구조를 제공하는 도메인 모델을 기반으로 소프트웨어 구조를 설계하면 변경에 유연하게 대응할 수 있는 탄력적인 소프트웨어를 만들 수있다.

불안정한 재료: 기능

유스케이스

• 기능적 요구사항이란 시스템이 사용자에게 제공해야 하는 기능의 목록을 정리한 것
• 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것을 '유스케이스'라고 한다.
• 유스케이스의 가치는 사용자들의 목표를 중심으로 시스템의 기능적인 요구사항들을 이야기 형식으로 묶을 수 있다는 점이다.

예제: 정기예금 이자 계산 유스케이스

유스케이스명: 중도 해지 이자액을 계산한다
일차 액터: 예금주

주요 성공 시나리오
1. 예금주가 정기예금 계좌를 선택한다.
2. 시스템은 정기예금 계좌 정보를 보여준다.
3. 예금주가 금일 기준으로 예금을 해지할 경우 지급받을 수 있는 이자 계산을 요청한다.
4. 시스템은 중도 해지 시 지급받을 수 있는 이자를 계산한 후 결과를 사용자에게 제공한다.

확장:
3a. 사용자는 해지 일자를 다른 일자로 입력할 수 있다.

유스케이스의 특성

• 첫째, 유스케이스는 사용자와 시스템 간의 상호작용을 보여주는 '텍스트'다.
  • 유스케이스는 다이어그램이 아니다.
  • 유스케이스의 핵심은 사용자와 시스템 간의 상호작용을 일련의 이야기 흐름으로 표현하는 것이다.
• 둘째, 유스케이스는 하나의 시나리오가 아니라 여러 시나리오들의 집합이다.
• 셋째, 유스케이스는 단순한 피처(feature) 목록과 다르다.
• 넷째, 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 한다.
• 다섯째, 유스케이스는 내부 설계와 관련된 정보를 포함하지 않는다.
  • 유스케이스의 목적은 연관된 시스템의 기능을 이야기 형식으로 모으는 것이지 내부 설계를 설명하는 것이 아니다.

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

• 유스케이스는 시스템의 내부 구조나 실행 메커니즘에 관한 어떤 정보도 제공하지 않는다.
• 유스케이스는 객체지향과도 상관이 없다.
• 유스케이스는 객체지향 이외의 패러다임에서도 적용 가능하며 객체지향은 유스케이스 이외의 방법으로 요구사항을 명시할 수도 있다.
• 유스케이스는 단지 기능적 요구사항을 사용자의 목표라는 문맥을 중심으로 묶기 위한 정리 기법일 뿐이다.

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

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

• 도메인 모델은 안정적인 구조를 개념화하기 위해, 유스케이스는 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구다.
• 객체지향 패러다임은 모든 것이 객체라는 사상에서 출발한다.
• 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보게 함으로써 객체 간의 안정적인 구조에 책임을 분배할 수 있는 출발점을 제공한다.
• 도메인 모델은 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공한다.
• 책임-주도 설계 방법은 시스템의 기능을 역할과 책임을 수행하는 객체들의 협력 관계로 바라보게 함으로써 두 가지 기본 재료인 유스케이스와 도메인 모델을 통합한다.

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

• 도메인 모델을 기반으로 객체 구조를 설계하는 이유는 도메인 모델이 안정적이기 때문이다.
  • 도메인 모델을 구성하는 개념은 비즈니스가 없어지거나 완전히 개편되지 않는 한 안정적으로 유지된다.
  • 도메인 모델을 구성하는 개념 간의 관계는 비즈니스 규칙을 기반으로 하기 때문에 비즈니스 정책이 크게 변경되지 않는 한 안정적으로 유지된다.
• 비즈니스 정책이나 규칙이 크게 변경되지 않는 한 시스템의 기능이 변경되더라도 객체 간의 관계는 일정하게 유지된다.
• 기능적인 요구사항이 변경될 경우 책임과 객체 간의 대응관계만 수정될 뿐이다.
• 이것은 변경에 대한 파급효과를 최소화하고 요구사항 변경에 유연하게 대응할 수 있는 시스템을 구축할 수 있게 한다.
• 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현할 경우 시스템의 기능이 변경되더라도 비즈니스의 핵심 정책이나 규칙이 변경되지 않는 한 전체적인 구조가 한 번에 흔들리지는 않는다.
• 이것이 일반적으로 객체지향이 기능의 변경에 대해 좀 더 유연하게 대응할 수 있는 패러다임이라고 일컬어지는 이유다.
• 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라.
• 도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라.

참고자료

객체지향의 사실과 오해(위키북스, 조영호 지음)