[Clean Architecture] 20장. 업무 규칙
|
Introduction
- 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차
- e.g. 은행이 돈을 버는 업무 규칙 - 대출에 N% 이자를 부과한다는 사실
- 핵심 업무 규칙
- Critical Business Rule
- 사업 자체에 핵심적
- 핵심 업무 규칙은 보통 데이터를 요구
- 이러한 데이터를 핵심 업무 데이터 (Critical Business Data)
- 시스템으로 자동화되지 않은 경우에도 존재하는 그런 데이터
- 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가됨
- 우리는 이러한 유형의 객체를 엔티티라고 함
엔티티
- 엔티티는 컴퓨터 시스템 내부의 객체
- 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화함
- 엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있음
- 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성됨
- 우리는 이러한 종류의 클래스를 생성할 때, 업무에서 핵심적인 개념을 구현하는 소프트웨어는 한데 모으고, 구축 중인 자동화 시스템의 나머지 모든 고려사항과 분리시킴
- 엔티티는 순전히 업무에 대한 것이며, 이외의 것은 없다
- 엔티티의 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것
유스케이스
- 모든 업무 규칙이 엔티티처럼 순수한 것은 아님
- 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무 규칙도 존재함
- 이러한 규칙은 자동화된 시스템의 요소로 존재해야만 의미가 있으므로 수동 환경에서는 사용될 수 없음
- 유스케이스는 자동화된 시스템이 사용되는 방법을 설명
- 유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술
- 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명함
- 유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할 지를 명시하는 규칙을 담음
- 엔티티가 어떻게 춤을 출지를 유스케이스가 제어하는 것
- 유스케이스는 사용자 인터페이스를 기술하지 않음
- 이 점은 매우 중요
- 유스케이스는 애플리케이션에 특화된 규칙을 설명하며 사용자와 엔티티 사이의 상호작용을 규정함
- 시스템에서 데이터가 들어오고 나가는 방식은 유스케이스와 무관함
- 유스케이스는 객체
- 유스케이스는 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공
- 또한 유스케이스는 입력 데이터, 출력 데이터, 유스케이스가 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함함
- 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못함
- 이는 의존성 역전 원칙을 준수하는 의존성 방향에 대한 또 다른 예
- 엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무 것도 알지 못함
- 반대로 저수준인 유스케이스는 고수준인 엔티티에 대해 알고 있음
- 왜 엔티티는 고수준이며, 유스케이스는 저수준일까?
- 유스케이스는 단일 애플리케이션에 특화
- 따라서 해당 시스템의 입력과 출력에 보다 가깝게 위치하기 때문
- 엔티티는 수많은 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것
- 각 시스템의 입력이나 출력에서 더 멀리 떨어져 있음
- 유스케이스는 엔티티에 의존함
- 엔티티는 유스케이스에 의존하지 않음
요청 및 응답 모델
- 유스케이스는 입력 데이터를 받아서 출력 데이터를 생성
- 유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환함
- 이들 데이터 구조는 어떤 것에도 의존하지 않음
- 의존성을 제거하는 일은 매우 중요
- 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스에도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합되어 버림
- 엔티티 객체를 가리키는 참조를 요청 및 응답 데이터 구조에 포함하려는 유혹을 받을 수 있음
- 엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유하므로 적합해 보임
- 하지만 이 유혹을 떨쳐내라
- 이들 두 객체의 목적은 완전히 다름
결론
- 업무 규칙은 소프트웨어 시스템이 존재하는 이유
- 업무 규칙은 핵심적인 기능
- 업무 규칙은 수익을 내고 비용을 줄이는 코드를 수반함
- 업무 규칙은 집안의 가보
- 업무 규칙은 사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안되며, 원래 그대로의 모습으로 남아 있어야 함
- 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 함