성장, 그리고 노력

부족하더라도 어제보다 더 잘해지자. 노력은 절대 배신하지 않는다.

도구, 기술, 이론/이론

[클린 아키텍처] 업무 규칙

제이콥(JACOB) 2020. 2. 14. 18:48

업무 규칙

 업무 규칙에는 여러 가지가 존재한다. 업무 규칙이란 쉽게 말하면 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차이다. 컴퓨터상으로 구현했는지 여부는 중요하지 않다. 예를 들어 대출에 N%의 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙이다. 이것을 컴퓨터가 계산하건 직원이 계산하건 중요하지 않다.

 

 그리고 이러한 규칙을 클린 아키텍처에서는 핵심 업무 규칙(Critical Business Rule)이라고 부른다. 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그래도 존재하기 때문이다. 이러한 핵심 규칙은 보통 데이터를 요구한다. 예를 들어 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다. 클린 아키텍처에서는 이를 핵심 업무 데이터(Critical Business Data)라고 부른다. 심지어 이러한 데이터는 시스템으로 자동화되지 않는 경우에도 존재하는 그런 데이터이다. 

 

 업무 규칙은 사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안 되며, 원래의 모습을 유지해야 한다. 이상적으로는 중요한 업무 규칙을 두고, 덜 중요한 코드는 플러그인 되어야 한다. 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.

 

 핵심 규칙 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 수 있으며 이러한 유형의 객체를 엔티티(Entity)라고 한다.

 

엔티티(Entity)

 엔티티는 컴퓨터 시스템의 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화한다. 엔티티 객체핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있다. 엔티티의 인터페이스핵심 업무 데이터를 기반으로 동작하는 핵심 규칙을 구현한 함수들로 구성된다

 위의 Loan 엔티티는 3가지의 핵심 업무 데이터를 포함하며, 데이터와 관련된 3가지 핵심 업무 규칙을 인터페이스로 제공한다. 이렇게 구현한 클래스(클래스를 사용하더라도 절대 객체지향의 의존적 개념은 아니다!)는 독립적으로 존재하며, 데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 오염되어서는 절대 안 된다. 엔티티는 순전히 업무에 대한 것이며, 이외의 것은 없다. 엔티티의 생성의 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것이다.

 

유스 케이스

 모든 업무 규칙이 엔티티처럼 순수한 것은 아니다. 자동화된 시스템이 동작하는 방법을 제약함으로써 수익을 얻거나 비용을 줄이는 업무 규칙도 존재한다. 

유스케이스 예제

 유스케이스(use case)는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술하며, 자동화된 시스템이 사용되는 방법을 설명한다. 엔티티 내의 핵심 업무 규칙과는 반대로, 유스 케이스는 애플리케이션에 특화된 업무 규칙을 설명한다. 즉 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담는다. 

 

 유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다. 이보다는 애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정한다. 시스템에서 데이터가 들어오고 나가는 방식은 유스 케이스와는 무관한 것이다. 

 

 유스케이스는 객체이다. 애플리케이션에 특화된 업무 규칙을 구현하나 하나 이상의 함수를 제공한다. 입력 데이터, 출력 데이터, 유스 케이스가 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함한다. 

 

 엔티티는 고수준이며, 유스케이스는 저수준이다. 유스 케이스는 단일 애플리케이션에 특화되어 있으며, 해당 시스템의 입력과 출력에 보다 가깝게 위치한다. 유스 케이스는 엔티티에 의존하지만 엔티티는 유스 케이스에 의존하지 않는다. 

 

요청 및 응답 모델

 요청 및 응답 모델 또한 독립적이어야 한다. 독립적이지 않다면 그 모델에 의존하는 유스케이스도 결국 해달 모델이 수반하는 의존성에 간접적으로 결합되어 버린다.

반응형