6장 | 객체 지도

🔥 자주 변경되는 기능이 아니라 안정적인 구조를 따라 역할, 책임, 협력을 구성하라

미래에 대비하는 가장 좋은 방법은 변경을 예측하는 것이 아니라 변경을 수용할 수 있는 선택의 여지를 설계에 마련해 놓는 것이다.

💻 기능 설계 vs 구조 설계

• 기능(function) 설계: 제품이 사용자를 위해 무엇을 할 수 있는가
• 구조(structure) 설계: 제품의 형태가 어떠해야 하는가
• 기능과 구조라는 두 가지 측면을 함께 녹여 조화를 이루도록 만들어야 한다.
• 즉, 훌륭한 기능을 제공하는 동시에 새로운 기능을 빠르고 안정적으로 추가할 수 있어야 한다.

💻 두 가지 재료: 기능과 구조

안정적인 재료: 구조

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

도메인 모델

• 도메인(domain): 사용자가 프로그램을 사용하는 대상 분야
• 도메인 모델: 소프트웨어가 목적하는 영역 내의 개념과 개념 간의 관계 등을 주의 깊게 추상화한 형태
• 최종 제품은 사용자의 관점을 반영해야 한다. 디자인 모델을 기반으로 만든 시스템이 사용자 모델을 정확하게 반영하도록 노력해야 한다.
• 따라서, 소프트웨어 객체는 도메인 모델을 통해 표현되는 도메인 객체들을 은유해야 한다.

불안정한 재료: 기능

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

유즈케이스

• 사용자와 시스템 간 이뤄지는 상호작용의 흐름을 정리하는 기법
• 사용자들의 목표를 중심으로 연관된 시스템의 기능적 요구사항들을 이야기 형식으로 묶을 수 있다.
• 도메인과 객체는 유즈케이스로부터 자동으로 변환되는 것이 아니며, 영감이나 힌트만이 들어 있을 뿐이다.

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

책임-주도 설계

• 요구사항들을 식별하고 도메인 모델을 생성한 후, 소프트웨어 클래스에 메소드를 추가하고, 요구사항을 충족시키기 위한 객체들 간 메시지 전송을 정의한다.
• 사용자의 관점에서 시스템의 기능을 명시하고, 사용자와 설계자가 공유하는 안정적인 구조를 기반으로 기능을 책임으로 변환하는 체계적인 절차를 따라야 한다.
• 안정적인 도메인 모델을 기반으로 시스템의 기능을 구현하라.
• 도메인 모델과 코드를 밀접하게 연관시키기 위해 노력하라.

📝 느낀점

간단한 예시와 함께 실제 사용자의 요구사항을 도메인과 클래스로 변환하는 법에 대하여 배울 수 있었다. 내가 프로젝트를 하며 했던 진행방식과 가장 크게 다른 점은, 유즈케이스를 똑바로 작성한 후 그로부터 도메인을 이끌어냈다는 점이다. 내가 프로젝트를 할 때는 유즈케이스를 정리하거나 검토하지 않은 상태에서, 머릿속으로 시나리오를 떠올리고 바로 클래스를 만드는 식으로 진행했었다. 생각해보면 그렇기 때문에 뒤로 갈수록 망할 수 밖에 없었던 방법인 것 같다. 개인 프로젝트를 할 때는 확실히 요구사항과 내용을 정리하고 차근차근 단계를 밟아가며 공부를 해보고 싶다.