객체 지도

모르는 장소에서 길을 찾을 때 어떤 방법을 선호하시나요? 대표적인 방법으로는 주변 사람들에게 길을 묻거나 지도를 확인하는 방법이 존재합니다. 길을 묻는 방법은 기능적이고 해결책 지향적인 접근 방법입니다. 하지만 이 방법은 일반적이지도 재사용할 수 있지도 않습니다. 위치는 상대적이기 때문에 시간이 지나면서 정보가 희미해져 갑니다.

 

지도를 확인하는 방법은 구조적이고 문제 지향적인 접근 방법입니다. 지도는 실제 세계를 추상화시켜 놓은 것이기에 풍부한 컨텍스트 정보가 담겨 있습니다. 이는 재사용 가능하며 길을 찾는 목적 이외에도 다양하게 활용할 수 있습니다.

 

여기서 주목해야 할 키워드는 기능과 구조입니다. 기능에 초점을 맞추다 보면 변화하는 요구사항에 대응하기 어렵습니다. 하지만 구조가 중심이 된다면 재사용할 수 있으며 변경에 유연하게 대처할 수 있게 됩니다.

기능 설계 대 구조 설계

모든 소프트웨어 설계의 측면에는 두 가지가 존재합니다.

• 기능 측면의 설계
• 구조 측면의 설계

훌륭한 기능이 훌륭한 소프트웨어를 만드는 충분조건이라고 한다면, 훌륭한 구조는 훌륭한 소프트웨어를 만드는 필수조건입니다. 소프트웨어를 사용하는 입장에서 중요한 것은 기능일지도 모릅니다. 그렇다면 기능에 초점을 맞추는 게 좋지 않을까요?

 

그렇지 않습니다. 요구사항이 변하지 않는다면 기능에 초점에 맞추는 것이 좋을 수도 있습니다. 하지만 변하지 않는 요구사항은 존재하지 않습니다. 잠깐 사이에 변하는 게 사람 마음이라고 요구사항 또한 짧은 시간에 변하게 됩니다. 그렇기에 변화에 유연한 구조에 초점을 맞추는 것이 중요합니다.

 

미래지향적인 구조를 처음부터 생각하는 것은 쉬운 일이 아닙니다. 그렇기에 설계는 공학이 아니라 예술이라고도 불린다고 합니다. 미래 변경을 대비할 수는 있지만 예측할 수는 없습니다. 좋은 설계는 미래에 어떤 변경이 발생할지 예측하는 것이 아닌 변경할 수 있는 여지를 남겨두는 것입니다.

 

이것이 객체를 기반으로 책임과 역할을 식별하고 메시지를 기반으로 객체들의 협력 관계를 구축하는 이유입니다. 객체 지도는 빠르게 변화하는 기능을 수용할 수 있도록 합니다.

안정적인 재료: 구조

특정 분야의 문제를 해결하기 위해 소프트웨어를 사용합니다. 소프트웨어를 사용하여 해결하고자 하는 분야를 도메인이라고 합니다. 도메인 모델에서 모델은 대상은 단순화해서 표현한 것을 의미합니다. 여기서 도메인 모델은 소프트웨어가 목적하는 영역 내의 개념과 개념 간의 관계, 다양한 규칙이나 제약 등을 주의 깊게 추상화한 것입니다.

 

객체지향은 도메인의 구조와 최대한 유사하게 코드를 구조화할 수 있습니다. 하지만 소프트웨어의 객체는 현실 세계의 객체를 모방한 것이 아닙니다. 소프트웨어 객체는 현실 세계의 은유를 바탕으로 새롭게 만들어낸 창조물입니다. 이런 차이를 표현적 차이 또는 의미적 차이라고 합니다.

 

표현적 차이를 잘 이해한다면 코드의 구조가 도메인 구조를 반영하기에 소프트웨어를 이해하고 수정하기 쉽게 만들어 줍니다. 도메인 모델이 도메인과 관련된 중요한 개념과 관계를 보여준다고 하더라도 실제로 중요한 것은 사용자에게 제공하는 기능입니다. 따라서 사용자에게 제공할 기능에 관한 기술이 필요한데 유스케이스라는 유용한 기법을 사용해 왔습니다.

불안정한 재료: 기능

클라이언트는 자신의 목표를 달성하기 위해서 시스템과 상호작용합니다. 그 과정에서도 많은 연결이 발생하게 되는데 클라이언트와 시스템 간에 이뤄지는 상호작용의 흐름을 텍스트로 정리한 것이 유스케이스입니다. 흩어져 있는 기능들에 사용자 목표라는 문맥을 제공해서 각 기능이 유기적인 관계를 맺은 체계를 이룰 수 있도록 합니다.

유스케이스의 특성

첫째, 유스케이스는 사용자와 시스템 간의 상호작용을 나타내는 텍스트입니다.

중요한 것은 다이어그램을 잘 그리는 것이 아닌 문맥을 잘 풀어나가는 것에 있습니다.

둘째, 유스케이스는 하나의 시나리오가 아닌 여러 시나리오의 집합입니다.

목표를 달성하기 위한 하나의 시나리오만 존재하는 것이 아닌 여러 시나리오가 유기적으로 연결되어 있습니다.

셋째, 유스케이스는 단순한 피처 목록과는 다릅니다. 피처는 시스템이 수행해야 하는 기능을 단순하게 나열한 것입니다.

기능 나열이 목적이 아닌 문맥을 잘 풀어내는 것에 초점을 맞춰야 합니다.

넷째, 유스케이스는 사용자 인터페이스와 관련된 세부 정보를 포함하지 말아야 합니다.

인터페이스 요소를 배제하고 시스템 행위에 초점을 맞춰야 본질적인 유스케이스라고 할 수 있습니다.

다섯째, 유스케이스는 내부 설계와 관련된 정보를 포함하지 않습니다.

유스케이스는 시스템 기능을 이야기로 모으는 것이지 내부 설계를 설명하는 것이 아닙니다. 내부 설계를 설명하는 좋은 방법은 유스케이스가 아니더라도 많이 존재합니다.

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

도메인 모델은 안정적인 구조를 개념화하기 위해 유스케이스는 불안정한 기능을 서술하기 위해 가장 일반적으로 사용되는 도구입니다. 변경에 유연한 소프트웨어를 만들기 위해서는 유스케이스에 정리된 시스템의 기능을 도메인 모델을 기반으로 한 객체들의 책임으로 분배해야 합니다.

 

이러한 관점에서 시스템도 사용자와의 경계에 존재하는 하나의 객체라고 볼 수 있습니다. 시스템에 할당된 큰 책임은 시스템 안의 작은 규모의 객체들이 수행해야 할 작은 규모의 책임으로 세분화됩니다.

 

결국 안정적인 도메인 모델을 기반으로 시스템 기능을 구현해야 합니다. 그것이 유지보수하기 쉽고 유연한 객체지향 시스템을 만드는 첫걸음이 될 것입니다.