[스터디: 객체지향의 사실과 오해] 도메인 모델과 유스케이스

기능 중심 vs 구조 중심

해운대에 가기 위해서 길을 알아봐야 한다면, 아래 2가지 방법을 사용할 수 있다.

1. 부산에 사는 친구에게 해운대에 어떻게 가는지 물어본다.
2. 부산 지도를 보고 해운대로 가는 길을 직접 찾는다.

 

1번 방법을 사용하면, 해운대에 가는 방법은 빠르게 알 수 있다.

하지만 목적지가 변경되어 광안리로 가야하는 상황에서는 다시 광안리로 가는 길을 물어보아야 한다.

이전에 썻던 방법을 재사용 할 수 없는 것이다.

 

하지만, 2번 방법을 사용하면, 목적지가 변경되더라도 똑같은 방법을 사용하여 길을 찾을 수 있다.

구체적으로 해운대로 가는 방법에 초점을 맞추지 않고, 전체적인 구조에 초점을 맞추었기 때문이다.

 

목적지가 해운대에서 광안리로 바뀐 것처럼, 프로그램에서도 요구사항은 계속 변한다.

요구사항이 바뀔 때마다 코드를 계속 변경해야 한다면, 시간이 많이 소모되고, 오류가 날 가능성도 커진다.

이러한 기능 변경을 모두 예측 할 수 없기 때문에, 변경에 대비하여 프로그램을 설계해야한다.

 

---

도메인 모델

최종 제품은 사용자의 관점을 반영해야한다.

 

예를 들어 커피 주문 서비스라면, 메뉴판, 주문을 받는 캐시어, 커피를 만드는 바리스타, 커피 와 같은 요소가 필요할 것이라고 쉽게 떠올릴 수 있다.

 

이렇게, 사용자가 프로그램을 사용하는 대상 영역에 관한 지식을 단순화한 구조를 도메인 모델이라고 한다.

 

도메인 모델을 바탕으로 설계하면 아래와 같은 장점을 가진다.

1. 구조에 대한 이해와, 수정을 쉽게 할 수 있다.
2. 안정적인 구조를 제공하기 때문에 변경될 가능성이 적다.

 

도메인 모델을 바탕으로 객체를 설계하면 객체들의 협력관계가 실제 서비스와 비슷한 구조를 가지기 때문에, 이해와 수정이 쉽다.

 

또한, 사용자의 관점에서 작성된 도메인 모델은 서비스의 본질적인 측면을 반영하기 때문에 변경될 가능성이 적다.

새로운 커피 메뉴가 추가되더라도 위에서 작성한 커피 주문 도메인 모델은 변경되지 않을 것이다.

 

이렇게 구조에 초점을 맞추어 설계하면, 이해하기 쉽고, 변경가능성과 대체가능성을 높일 수 있다.

 

---

유스케이스

하지만 구조에 맞추어 설계하고, 기능적인 요구사항은 중요하지 않은 것은 아니다.

사용자가 시스템을 사용하는 이유는 커피 주문과 같은 목적을 달성하기 위함이고, 목적 달성을 위한 기능을 제공하는 것이 시스템의 역할이기 때문이다.

 

사용자는 커피주문이라는 목적을 달성하기 위해서, 시스템과 계속해서 상호작용 한다.

사용자: 커피 종류를 알려줘
시스템: 커피 종류를 보여준다
사용자: 이 커피를 만들어 줘
시스템: 결제 화면으로 이동한다
사용자: 결제한다
시스템: 커피 제조하여, 커피를 사용자에게 전달한다

 

커피 주문이라는 하나의 목적을 달성하는데, 사용자는 쿠폰을 사용할 수도 있고, 카드로 결제할 수도 있다.

이렇게 사용자가 시스템을 사용하는 목적을 유스케이스라고 하고, 하나의 유스케이스에는 쿠폰을 사용하는 경우, 카드로 결제하는 경우 등 여러개의 시나리오가 포함된다.

 

또한, 커피 주문에는 주문, 결제, 커피 제조 와 같은 여러 기능들이 함께 합쳐져서 커피주문이라는 하나의 목적을 달성한다.

만약, 손님이 케이크를 주문한다 하더라도 주문과 결제 기능은 똑같이 사용될 수 있다.

이렇게 하나의 유스케이스는 서로 다른 기능들을 하나로 묶어서 전체 큰 목적을 달성한다.

 

이 내용을 읽으면서 웹 프로그래밍에서 컨트롤러를 설계하는 내용이 떠올랐다.

주문, 결제, 커피 제조를 서비스라고 한다면, 컨트롤러는 각각의 서비스를 호출하여 커피 제조라는 클라이언트의 요청을 달성한다.

 

사용자가 커피 주문 버튼을 누르면 커피주문 컨트롤러에서 요청을 받아서 각각의 서비스를 호출해준다.

이때, 사용자는 시스템이 커피를 주문해주는 것만 알 뿐 내부에서 어떤 서비스가 호출되는지 모를 것이다.

💡 결국, 유스케이스는 내부 구조는 모르고, 외부에 제공하는 시스템의 행위에만 초점을 맞추어야 한다.

 

---

도메인 모델, 유스케이스

유스케이스와 도메인 모델을 활용해서 어떻게 객체지향적 설계를 할 수 있을까?

 

1. 사용자에게 제공되어야 하는 기능을 생각한다. (유스케이스)
2. 전체 기능을 여러개의 객체의 책임으로 분리한다.
3. 도메인 모델을 바탕으로 필요한 객체를 떠올린다.
3. 설정한 책임들을 도메인 객체에 각각 부여한다.

 

1. 커피 주문 시스템을 만들고자 한다면 커피 주문 시스템 전체의 책임은 커피 주문을 수행하는 것이다.

2. 이 책임을 한개의 객체가 수행하기에는 너무 복잡하기 때문에 주문, 결제, 제조 책임으로 분리한다.

3. 커피 주문에서는 메뉴판, 캐시어, 바리스타, 커피 와 같은 객체가 필요하다.

4. 커피 주문과 결제는 캐시어에게, 커피 제조는 바리스타의 책임으로 할당한다.

 

위 예시에서 유스케이스는 사용자에게 제공할 기능을 시스템의 책임으로 보는 출발점을 제공한다.

도메인 모델은 기능 수행을 목표로 객체들을 설계하기 위한 안정적인 구조를 제공한다.

 

이러한 방식으로 설계를 하면 기능이 변경되더라도 객체간의 대응관계만 수정하면 된다.

만약 커피외에 케이크도 주문한다면, 바리스타가 아닌 제빵사에게 캐시어가 케익 제조를 요청하면 될 것이다.

 

결국, 안정적인 도메인 모델을 기반으로 유지 보수가 쉽고 유연한 서비스를 만들 수 있다는 것이다.

 

이번 장에서 도메인 모델과, 유스케이스에 대해 설명하며, 이 도구들이 어떻게 객체지향적 설계를 도와주는지 강조한다.

 

평소에도 도메인 모델을 바탕으로 설계를 하곤 했는데, 제대로 설계한게 맞는지 유스케이스를 만들어 가며 해피에이징 프로젝트에 적용해 보았다.

[해피에이징 프로젝트에 적용 완료 후 내용 추가]