기능을 중심으로 구조를 종속시키는 적근법은 범용적이지 않고 재사용이 불가능하며 변경에 취약한 모델을 낳게 된다. 이와 달리 안정적인 구조를 중심으로 기능을 종속시키는 접근법은 범용적이고 재사용 가능하며 변경에 유연하게 대처할 수 있는 모델을 만든다. (중략) 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라. (p.180)
기능 설계 vs 구조 설계
- 성공적인 소프트웨어 -> 사용자가 원하는 새로운 기능을 빠르고 안정적으로 추가할 수 있다
- 이는 훌륭한 구조가 뒷받침되어 있기에 가능한 것
- 비록 최종 사용자들은 내부 구조를 볼 수 없지만, 좋은 설계는 사용자의 요구사항을 빠르게 반영할 수 있기에 중요하다
- 설계라는 행위를 중요하게 만드는 것은 변경에 대한 필요성이다
- 설계를 하는 목적은 나중에 설계하는 것을 허용하는 것이며 설계의 목표는 변경의 비용을 낮추는 것
- 변경을 예측하지 말고 변경을 수용할 수 있는 선택의 여지를 설계에 마련해두라
- 이를 위한 가장 좋은 방법은 기능이 아닌 구조를 중심으로 설계하는 것
- 기능을 중심으로 설계하면 기능들이 밀접하게 연관되어 있어 하나의 수정이 전체 소프트웨어 구조를 흔들게 된다
- 객체를 이용해 지도를 만들고, 기능이 객체로 만들어진 길을 따라 자연스럽게 흘러가게 하라
두 가지 재료 : 기능과 구조
- 구조 : 이해관계자들이 도메인(domain)에 관해 생각하는 개념과 개념들 간의 관계로 표현
- 도메인 모델링, 도메인 모델
- 기능 : 사용자의 목표를 만족시키기 위해 책임을 수행하는 시스템의 행위로 표현
- 유스케이스 모델링, 유스케이스 모델
안정적 재료 : 구조
도메인 모델
- 도메인 : 사용자가 프로그램을 사용하는 대상 분야
- 도메인 모델 : 도메인에 대한 지식을 (문제에 관련된 측면만) 선택적으로 단순화하고 의식적으로 구조화한 형태
- 도메인 모델은 단순 다이어그램이 아님. 이해관계자들이 바라보는 멘탈 모델 (사람들이 자신과 상호작용하는 사물, 사람, 환경 등에 대해 갖는 모형으로 현상을 이해하고 거기에 반응하기 위해 각자가 구축함) 이다.
- 애플리케이션은 도메인 모델을 기반으로 설계되어야 한다
- 즉, 소프트웨어의 코드는 사용자들이 도메인을 바라보는 관점과 설계자가 시스템의 구조를 바라보는 관점을 기반으로 설계되어야 한다
- 객체지향을 사용하면 도메인 모델을 사용자들의 이해와 최대한 유사하게 코드로 구조화할 수 있다 (표현적 차이)
표현적 차이
- 객체지향은 현실 객체에 대한 추상화가 아니라 은유를 기반으로 재창조한 것이다
- 즉, 소프트웨어 객체는 현실 객체의 특성을 기반으로 구축되며 이때의 의미적 거리를 표현적 차이라고 한다
- 우리가 은유를 통해 투영해야 하는 대상은 사용자가 도메인에 대해 생각하는 개념 (도메인 모델)
- 코드의 구조가 도메인의 구조를 반영하면 소프트웨어가 이해하고 수정하기 쉬워진다
불안정한 기능을 담는 안정적인 도메인 모델
- 도메인 구조는 상대적으로 안정적 -> 도메인 모델을 기반으로 코드 작성 이유
- 사용자 모델이 반영된 도메인 구조는 비교적 변경될 확률이 적다
- 도메인 모델은 기능을 구현할 때 참조할 수 있는 궁극적인 지도
- 도메인 모델은 비즈니스의 개념과 정책을 반영하는 안정적 구조를 제공
불안정한 재료 : 기능
유스케이스
- 유스케이스 : 사용자의 목표를 달성하기 위해 사용자와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것
- 사용자의 목표를 중심으로 시스템의 기능 요구사항들을 이야기(시나리오) 형태로 묶을 수 있다는 가치가 있다
- 훌륭한 기능적 요구사항을 얻기 위해서는 유스케이스(상호작용)를 중심으로 시스템을 바라봐야 한다
유스케이스의 특성
- 중요한 것은 다이어그램이 아니라, 사용자와 시스템 간 상호작용의 흐름 (시나리오)
- 유스케이스는 여러 시나리오의 집합
- 주요 성공 시나리오를 비롯해 대안 흐름(시나리오)를 같이 포함
- 즉, 유스케이스는 사용자의 목표를 달성하기 위한 모든 시나리오(유스케이스 인스턴스)의 집합
- 단순 feature의 목록이 아니라, 사용자와의 상호작용 속에서 feature들을 포함하는 이야기(시스템의 기능)를 제공
- 본질적인 유스케이스 - 특정 feature를 사용하기 위한 사용자 인터페이스 등 자주 변경되는 요소는 배제하고 시스템의 행위에 초점을 맞춘다
- 내부 설계와 관련된 정보를 포함하지 않는다
- 유스케이스는 내부 설계에 대한 설명이 아니다
- 유스케이스는 설계 기법도, 객체지향 기법도 아니다!
기능과 구조의 통합
도메인 모델, 유스케이스, 책임-주도 설계
- 유스케이스에 정리된 시스템의 기능(책임)을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 함
- 시스템의 책임을 작은 객체의 책임으로 분배할 때 도메인 모델에 포함된 개념을 은유하는 소프트웨어 객체를 선택해야 함
책임-주도 설계는 유스케이스로부터 첫 번째 메시지와 사용자가 달성하려는 목표를, 도메인 모델로부터 기능을 수용하기 위해 은유할 수 있는 안정적인 구조를 제공받아 실제로 동작하는 객체들의 협력 공동체를 창조한다. (p.199)
설계 방법 예시
- 책 p.199 ~ p.201 참고
- 시스템의 책임이 있을 때 메시지를 받을 객체(책임 수행을 시작)를 먼저 선택하고 (도메인 모델 참조)
- 그 객체가 다른 객체에 전송할 메시지를 식별한 후
- 다시 그 메시지를 받을 객체를 선택 -> 협력 관계를 창조
실세계에서는 수동적인 존재라고 하더라도 소프트웨어 객체로 구현될 때는 스스로 판단하고 행동하는 자율적인 존재로 변한다. (p.201)
- 책임 할당의 기본 원칙 -> 책임을 수행하는 데 필요한 정보를 가진 객체에게 그 책임을 할당
- 상태와 행동을 캡슐화하게 됨
기능 변경 발생 시
- 비즈니스 정책이나 규칙이 크게 변경되지 않는 한, 시스템의 기능이 변경되더라도 객체 간의 관계를 일정하게 유지됨
- 안정적인 도메인 모델을 중심으로 객체 구조를 설계하고, 유스케이스의 기능을 객체의 책임으로 분배했기 때문
- 기능 요구사항이 변경되면 책임과 객체의 대응 관계만 수정됨
사람들이 동일한 용어와 동일한 개념을 이용해 의사소통하고 코드로부터 도메인 모델을 유추할 수 있게 하는 것이 도메인 모델의 진정한 목표다. (중략) 도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라. 그것이 유지보수하기 쉽고 유연한 객체지향 시스템을 만드는 첫걸음이 될 것이다. (p.206)
질문
- p.183 무슨 말이지ㅜ
- p.205 - 도메인을 프로그래밍하기 위한 기법과 도메인을 모델링하기 위해 사용하는 기법이 같다는게 무슨 의미인지
이 게시글은 스터디에서 [ 객체지향의 사실과 오해 / 조영호 ] 책을 읽고 중요한 내용을 잊지 않기 위해 정리한 게시글입니다. 요약 및 생략된 내용이 많고 제가 이해한 대로 다시 정리한 내용이라 보다 자세하고 정확한 설명은 책 구매를 권장합니다.