[Clean Architecture] 20장. 업무 규칙

Introduction

• 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차
  • e.g. 은행이 돈을 버는 업무 규칙 - 대출에 N% 이자를 부과한다는 사실
• 핵심 업무 규칙
  • Critical Business Rule
  • 사업 자체에 핵심적
• 핵심 업무 규칙은 보통 데이터를 요구
  • 이러한 데이터를 핵심 업무 데이터 (Critical Business Data)
  • 시스템으로 자동화되지 않은 경우에도 존재하는 그런 데이터
• 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가됨
• 우리는 이러한 유형의 객체를 엔티티라고 함

엔티티

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

• 우리는 이러한 종류의 클래스를 생성할 때, 업무에서 핵심적인 개념을 구현하는 소프트웨어는 한데 모으고, 구축 중인 자동화 시스템의 나머지 모든 고려사항과 분리시킴
• 엔티티는 순전히 업무에 대한 것이며, 이외의 것은 없다
• 엔티티의 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것
  • 꼭 객체 지향 언어를 사용할 필요는 없다

유스케이스

• 모든 업무 규칙이 엔티티처럼 순수한 것은 아님
• 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무 규칙도 존재함
• 이러한 규칙은 자동화된 시스템의 요소로 존재해야만 의미가 있으므로 수동 환경에서는 사용될 수 없음
• 유스케이스는 자동화된 시스템이 사용되는 방법을 설명
• 유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술
• 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명함
• 유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할 지를 명시하는 규칙을 담음
  • 엔티티가 어떻게 춤을 출지를 유스케이스가 제어하는 것
• 유스케이스는 사용자 인터페이스를 기술하지 않음
  • 이 점은 매우 중요
  • 유스케이스는 애플리케이션에 특화된 규칙을 설명하며 사용자와 엔티티 사이의 상호작용을 규정함
  • 시스템에서 데이터가 들어오고 나가는 방식은 유스케이스와 무관함
• 유스케이스는 객체
  • 유스케이스는 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공
  • 또한 유스케이스는 입력 데이터, 출력 데이터, 유스케이스가 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함함
• 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못함
  • 이는 의존성 역전 원칙을 준수하는 의존성 방향에 대한 또 다른 예
• 엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무 것도 알지 못함
• 반대로 저수준인 유스케이스는 고수준인 엔티티에 대해 알고 있음
• 왜 엔티티는 고수준이며, 유스케이스는 저수준일까?
  • 유스케이스는 단일 애플리케이션에 특화
    • 따라서 해당 시스템의 입력과 출력에 보다 가깝게 위치하기 때문
  • 엔티티는 수많은 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것
    • 각 시스템의 입력이나 출력에서 더 멀리 떨어져 있음
  • 유스케이스는 엔티티에 의존함
  • 엔티티는 유스케이스에 의존하지 않음

요청 및 응답 모델

• 유스케이스는 입력 데이터를 받아서 출력 데이터를 생성
• 유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환함
• 이들 데이터 구조는 어떤 것에도 의존하지 않음
• 의존성을 제거하는 일은 매우 중요
  • 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스에도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합되어 버림
• 엔티티 객체를 가리키는 참조를 요청 및 응답 데이터 구조에 포함하려는 유혹을 받을 수 있음
  • 엔티티와 요청/응답 모델은 상당히 많은 데이터를 공유하므로 적합해 보임
  • 하지만 이 유혹을 떨쳐내라
  • 이들 두 객체의 목적은 완전히 다름

결론

• 업무 규칙은 소프트웨어 시스템이 존재하는 이유
• 업무 규칙은 핵심적인 기능
• 업무 규칙은 수익을 내고 비용을 줄이는 코드를 수반함
• 업무 규칙은 집안의 가보
• 업무 규칙은 사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안되며, 원래 그대로의 모습으로 남아 있어야 함
• 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 함