독서(Reading)/클린아키텍처(Clean Architecture)

5부 아키텍처 20장 업무 규칙

Chaany 2022. 12. 30.
728x90

1. 들어가며

  • 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다.
  • 핵심 업무 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 존재하는 업무 규칙
  • 핵심 업무 데이터는 시스템이 자동화되지 않은 경우에도 존재하는 데이터
  • 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 됨
    • 해당 유형의 객체를 엔티티라고 함

2. 엔티티

  • 엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체함
  • 엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있음
  • 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성됨
  • 업무에서 핵심적인 개념을 구현하는 소프트웨어는 한데 모으고, 구축 중인 자동화 시스템의 나머지 모든 고려사항과 분리시킴
  • 업무의 대표자로서 독립적으로 존재하며, 데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 안됨
  • 어떤 시스템에서도 업무를 수행할 수 있으며, 시스템의 표현 형식이나 데이터 저장 방식, 그리고 해당 시스템에서 컴퓨터가 배치되는 방식과도 무관함
  • 엔티티는 순전히 업무에 대한 것
  • 엔티티를 만드는 데 꼭 객체 지향 언어를 사용할 필요는 없음
  • 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것

3. 유스케이스

  • 자동화된 시스템이 사용되는 방법을 설명함
  • 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 그리고 해당 출력을 생성하기 위한 처리 단계를 기술함
  • 엔티티 내의 핵심 업무 규칙과는 반대로, 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명함
  • 유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담음, 즉 엔티티가 어떻게 춤을 출지를
  • 유스케이스가 제어하는 것
  • 사용자에게 어떻게 보이는지를 설명하지 않음
  • 애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정함
  • 시스템에서 데이터가 들어오고 나가는 방식은 유스케이스와 무관함
  • 유스케이스는 객체이며, 애플리케이션에 특화된 업무 규칙을 구현하는 하나 이상의 함수를 제공함
  • 입력 데이터, 출력 데이터, 유스케이스가 상호작용하는 엔티티에 대한 참조 데이터 등의 데이터 요소를 포함함
  • 의존성 역전 원칙을 준수하는 의존성 방향에 대한 사레로, 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못함
  • 유스케이스는 단일 애플리케이션에 특화되어 있으며, 해당 시스템의 입력과 출력에 보다 가깝게 위치하기 때문에 저수준임
  • 엔티티는 다양한 애플리케이션에서 사용될 수 있도록 일반화된 것, 각 시스템의 입력이나 출력에서 더 멀리 떨어져 있음
  • 유스케이스는 엔티티에 의존하지만 엔티티는 유스케이스에 의존하지 않음

4. 요청 및 응답 모델

  • 유스케이스는 입력 데이터를 받아서 출력 데이터를 생성함
  • 데이터를 사용자나 또 다른 컴포넌트와 주고 받는 방식에 대해서는 전혀 눈치챌 수 없어야 함, HTML이나 SQL에 대해 알게 되는 일을 원하지 않음
  • 유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환함, 이들 데이터 구조 외에는 의존하지 않음
  • 의존성을 제거하는 일은 매우 중요하며, 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합되어 버림
  • 엔티티 객체를 가리키는 참조를 요청 및 응답 데이터 구조에 포함하려는 유혹이 있겠지만 두 객체의 목적은 완전히 다름
  • 시간이 지나면 두 객체는 완전히 다른 이유로 변경될 것이며, 어떤 식으로든 함께 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 됨

결론

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

 

728x90

댓글