5. 비즈니스 요구사항과 회원 도메인 설계
다음 정의된 비즈니스 요구사항에 따라 도메인을 설계하고 개발해본다.
비즈니스 요구사항
- 회원
- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 VIP 두 가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수도, 외부 시스템과 연동할 수도 있다. (미확정)
- 주문과 할인 정책
- 회원은 상품을 주문할 수 있다.
- 회원 등급에 따라 할인 정책을 적용할 수 있다.
- 할인 정책은 우선 모든 VIP 등급에게 1000원을 할인해주는 고정 금액 할인을 적용한다.
- 할인 정책은 변경 가능성이 높다. 회사의 기본 할인 정책이 아직 미정일 수도 있고, 오픈 직전까지 고심하다가 결정될 수도 있다. 최악의 경우 할인을 아예 적용하지 않을 수도 있다. (미확정)
요구사항을 봤을 때, 회원 데이터, 할인 정책 등은 바로 결정하기 어려운 사항이다.
하지만, 그러한 사항들이 결정될 때까지 개발을 무기한 연기할 필요는 없다.
객체 지향 개발을 이용하면 일부 요구사항이 결정되지 않아도 개발을 진행할 수 있다.
앞서 학습한 역할과 구현의 분리, 즉 인퍼페이스와 구현체를 이용해 프로그램을 설계한다.
회원 도메인 설계
회원 도메인 요구사항
- 회원을 가입하고 조회할 수 있다.
- 회원은 일반과 VIP 두 가지 등급이 있다.
- 회원 데이터는 자체 DB를 구축할 수도, 외부 시스템과 연동할 수도 있다. (미확정)
회원 도메인 협력 관계
회원 도메인 협력 관계를 먼저 구성한다.
도메인 협력 관계는 기획자 등의 관계자도 함께 보는 일반적인 도식이다.
사실 이런 표현을 처음 들어보는데, 실무에서 사용하는 듯 하다.
- 클라이언트는 회원 서비스를 호출한다.
- 회원 서비스는 회원 가입, 회원 조회 기능을 제공한다.
- 회원 서비스는 회원 저장소로부터 회원 정보를 얻는다.
- 강의에서는 회원 데이터는 자체 DB를 통해 관리할 수도, 외부와 연동할 수도 있기 때문에, 회원 데이터에 접근하는 계층을 별도로 구성한 것이라 설명한다.
- 회원 저장소를 구성하는 것에 이유가 있다는 설명으로 보아, 데이터를 취급하는 방식에 따라 데이터 저장소를 다르게 구성하거나, 아예 없앨 수도 있는 모양이다.
회원 클래스 다이어그램
다음으로 도메인 협력 관계를 바탕으로 클래스 다이어그램을 구성한다.
클래스 다이어그램은 개발자가 구체화하여 설계하는 다이어그램이다.
앞서 서술했듯 도메인 협력 관계를 바탕으로 구성되며, 인터페이스와 구현 클래스 등이 구체적으로 명시된다.
회원 서비스 역할로 MemberService 인터페이스를 선언하고, MemberServiceImpl 클래스를 구현체로 설정한다.
일반적으로 인터페이스의 구현체가 하나밖에 없을 경우, 관례적으로 구현 클래스 이름에 Impl을 붙인다.
회원 서비스가 의존하는 회원 저장소 역할로 MemberRepository 인터페이스를 선언한다.
MemberRepository의 구현체로 MemoryMemberRepository 클래스와 DbMemberRepository 클래스를 설정한다.
+)
외부 시스템 연동 저장소는 정해진게 없으므로 구현체를 정의할 수 없다. 이후에 외부 시스템 연동 저장소가 정해진다면, MemberRepository의 구현체로 별도의 클래스를 새로 정의하면 그만이다. 중요한건 MemberRepository 인터페이스다.
회원 객체 다이어그램
마지막으로 객체 다이어그램을 구성한다.
객체 다이어그램은 런타임에 실제로 생성되고 참조되는 객체들의 관계를 구성한 다이어그램이다.
클라이언트는 회원 서비스에 접근하고, 회원 서비스는 메모리 회원 저장소에 접근한다.
회원 서비스의 구현체는 MemberServiceImpl이 유일하므로, 객체 다이어그램에서 회원 서비스에 들어갈 요소는 MemberServiceImpl로 고정이다.
이런 식으로 동적으로 결정되는 객체들의 관계는 클래스 다이어그램만으로는 파악하기 어렵기 때문에,
객체 다이어그램을 통해 파악해야 한다.
클래스 다이어그램 vs 객체 다이어그램
클래스 다이어그램은 비유하자면 프로그램의 구성도와 같다.
프로그램을 구성하는 인터페이스와 구현체, 그리고 그들 간의 관계를 정의한다.
클래스 다이어그램은 개발 시 참고하는 "정해진 것"이므로 정적 다이어그램으로 분류할 수 있다.
반면, 객체 다이어그램은 런타임에 실제로 생성되고 참조되는 객체들 간의 관계를 표현한 것이다.
이러한 관계는 실행 환경이나 정책에 따라 동적으로 변하기 때문에 동적 다이어그램으로 분류된다.
예를 들어, 메모리 회원 저장소의 구현체를 MemoryMemberRepository로 할지, DbMemberRepository로 할지 결정할 때, 클래스 다이어그램은 결정에 따라 변하지 않지만, 객체 다이어그램은 메모리 회원 저장소에 들어갈 요소가 바뀌므로 변한다는 점에서 차이가 있다.
간만에 쓰는데 글이 많다. 이론적인 내용이 많은 파트라서 어쩔 수 없긴 하지만, (요구사항, 도메인 설계, ...) 제대로 이해하지 않고 넘어가면 프로그램을 제대로 개발할 수 없다. 시간을 들여 잘 이해하고 넘어가자.
그리고 클래스 다이어그램, 객체 다이어그램 등의 내용은 정보처리기사에 나오는 내용이다. 당시에는 깊은 이해 없이 암기만 했었는데, 이렇게 실적용 사례를 보니 그때 공부했던 내용이 떠오르면서 잘 이해할 수 있었다.
이런 식으로 서로 연결되는 개념이 많기 때문에, 이론적인 부분을 결코 가볍게 넘겨선 안 된다.