Clean Architecture - 2. 클린 아키텍쳐의 핵심: Use Case

중요한건 Use case다.

 

클린아키텍쳐를 한마디로 표현하면, 그건 Use case다. 그럼 그 Use case라는게 뭘까.

Use case란 내가 만들고자하는 시스템(혹은 서비스라고 하자)을 사용하는 클라이언트가 그 시스템을 통해 하고자 하는 것을 말한다.

 

예를 들어, '영화관' 이라는 서비스가 있다고 가정해보자. 영화관에서 손님(클라이언트)는 '영화 예매'를 할 수도 있고, '예매 취소'를 할 수도 있고, '환불', 심지어 '팝콘 사기'를 할 수도 있을 것이다. 이 때, 이런 '영화 예매', '예매 취소', '환불', '팝콘 사기' 등등이, '영화관'이라는 시스템에 사용자가 요청할 수 있는, '영화관'의 Use case이다.

 

클린 아키텍쳐에서 말하는 좋은 아키텍쳐란, 아키텍쳐(설계도)가 그 시스템이 하고자 하는 것을 설명해야 한다는 것이다. 그리고 그것은, Apache, Django, MySQL, Redis 같은 도구가 아니고, 그것이 웹사이트 임을 유추할 수 있는 특정 웹 프레임워크의 폴더 구조도 아니다. 그것이 웹 서비스이든, 로컬에서 동작하는 서비스이든 관계없이, 해당 서비스가 클라이언트에게 어떤 기능을 제공해주는지 말해줄 수 있어야 좋은 아키텍쳐라는 것이다. 

 

Figure1. Use Case 예시

 

그것이 가능하게 되기 위해서는 Use case가 안정적으로 잘 만들어져 있어야 하고, 그 외의 도구들은 언제든지 바뀔 수 있으므로, 결합도를 최대한 낮추는 것(loose coupling)이 중요하다. 하나의 기능?만을 Use case라고 표현하면, 혹시 너무 심플한거 아닌가라고 생각할지 모르겠다. 실제로 본인이 만들고자 하는 서비스가 있어서, 그것을 Use case화 하고 구현해보면 결코 그것이 심플하지 않음을 완전히 깨닫게 되겠지만, Figure 1의 내용을 통해 간접 경험해보자.

 

Figure 1은 Use case의 예시이다. '주문하다'라는 하나의 Use case를 위해 필요한 데이터들과 그것이 처리되기 위해서 꽤 많은 절차와 그 상황에서 발생할 수 있는 예외 처리까지 필요하다는 것을 알 수 있다.

 

Figure2. Clean architecture

 

그럼 그 Use case를 툴 같은 외부 요인과 어떻게 분리(loose coupling)시킬 것인가. Figure 2는 방법을 대략적인 그림으로 나타낸 것이다. 여기서, Interactor가 Use case라고 생각하면 된다. 그리고, 그림에는 하나의 Interactor만 그려져있지만, Interactor와 Use case는 1:1 매칭되는 것이며, 때문에 하나의 서비스에서는 여러 Interactor가 있을 수 있다.

 

Interactor가 사용하는 Entity들은, Use case를 처리하기 위해 필요한 요소들이라고 생각하면 된다. 다시, '영화 예매'를 예로 들면, 우리가 서비스 시스템을 객체지향적으로 설계한다고 가정했을 때, '영화 예매'라는 로직을 처리하기 위한 구조를 '영화', '상영', '손님', '비용' 등의 객체들로 구성하고, 그 객체들의 협력으로 만들 수 있을 것이다. 이때 이 '영화', '상영', '손님', '비용'과 같은 것들이 Entity가 될 수 있는 것이다.

 

그리고, Use case와 툴을 포함한 그 외 외부를 나누기 위한 방법으로, 그림에서 표현한 것과 같이 Boundary라는 인터페이스를 둔다. 해당 인터페이스를 통해 Use case로 들어오는 요청을 모두 같은 형태로 들어오도록 만들고, Use case로 부터 응답이 나갈때도 항상 정해진 형태로 나갈 수 있도록 한다. 때문에 Delivery mech. 의 위치에 어떤 종류의 프레임워크가 붙어도 관계가 없어지는 것이다.

 

가령, 내가 파이썬 개발자라서, WAS 프레임워크로 Flask를 쓰든, Django를 쓰든 관계 없이, 해당 프레임워크로 들어온 요청을 Use case가 받아들일 수 있는 형태에 맞춰서 전달하고, 정해진 응답 형식에 맞게 처리해주면 되는 것이다.