4.3 유스케이스 중심의 아키텍처 구현

[jongfeel]

4.3 유스케이스 중심의 아키텍처 구현

4.3.1 유스케이스 선정

특정 유스케이스를 애플리케이션 기능으로 먼저 구현하면서, 동시에 필요한 공통 기능도 함께 구축해 나가는 전략이 효과적입니다.
이러한 접근 에서는 어떤 유스케이스를 우선적으로 구현할지 정하는 일이 중요해집니다.

샘플 유스케이스

이 방법은 다음과 같은 장점이 있습니다.

• 가상의 소재로도 작성할 수 있어, 요구사항 분석 없이 시작할 수 있다.
• 도메인 지식 없이도 아키텍트가 직접 작성하고 구조를 점검할 수 있다.
• 유스케이스의 복잡도와 난이도를 자유롭게 조절해, 기반 구현에 적합한 수준으로 맞출 수 있다.

반면, 단점은 다음과 같습니다.

• 샘플 특성상 실무와의 연관성이 낮아, 실제 구현 과정에서 공통 기능의 누락이나 결함이 뒤늦게 드러날 수 있다.
• 샘플용 데이터베이스 설계 등 실제 개발에 불필요한 작업이 추가될 수 있다.

실제 유스케이스

중요한 유스케이스란 실행을 통해 아키텍처의 핵심 요소를 검증할 수 있는 기능을 의미하며, 구체적으로는 다음과 같은 조건을 충족해야 합니다.

• 애플리케이션 기반에 필요한 공통 기능을 포괄할 수 있다.
• 애플리케이션의 모든 계층과 컴포넌트 유형을 경유하는 유스케이스 흐름을 포함한다.
• 데이터베이스 및 외부 서비스 연동 등 주요 시스템과의 연결을 검증할 수 있다.
• 처음 사용하는 라이브러리 등 기술적 리스크가 있는 요소를 검증할 수 있다.

실제 유스케이스를 사용하면 다음과 같은 장점이 있습니다.

• 실무 유스케이스를 활용하므로 공통 기능의 정확성과 실효성이 높아진다.
• 기술서부터 구현까지 모든 작업이 실제 개발에 활용되어 낭비가 없다.

반면, 다음과 같은 단점도 있습니다.

• 기술서를 작성하려면 업무 지식이 필요해, 업무 담당자의 협조가 필수적이다.
• 유스케이스가 복잡하거나 개발 난이도가 과도하게 높을 수 있다.

주요 성공 시나리오와 대표적인 예외 시나리오로만 구현해도 충분하며, 업무 규칙은 임시 구현(프로토타이핑)으로 대체할 수 있습니다.

4.3.2 유스케이스 구현

이 단계에서는 애플리케이션 아키텍처와 적용할 아키텍처 스타일이 이미 결정된 상태라고 가정합니다.
이 시점에서는 추상도를 컴포넌트 레벨까지 낮추고, 각 구성 요소의 책임을 할당하며 상호 작용을 구체화하는 작업이 필요합니다.