본문 바로가기

Design/Architecture

[Clean Architecture] 아키텍처 - 업무규칙 (Entity, Use case)

여태까지 수차례 언급해왔던 업무규칙에 대해서 알아보는 시간을 가져보자.

 

애플리케이션을 업무규칙과 플러그인으로 구분하려면 업무규칙이 무엇인지 정확히 이해할 필요가 있다.

 

업무규칙이란?

업무규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다.
  • 업무규칙은 컴퓨터로 구현을 했던 사람이 수동으로 수행을 하던 동일하다.
  • 이러한 규칙을 "핵심 업무 규칙(Critical Business Rules)"라고 부른다.
  • 핵심 업무 규칙은 보통 데이터를 요구하는데 이러한 데이터를 "핵심 업무 데이터(Critical Business Data)"라고 부른다.
    ex) 대출에는 대출 잔액, 이자율, 지급 일정 데이터가 필요하다.
  • 핵심 업무 규칙과 핵심 업무 데이터는 본질적으로 결합이 되어있기 때문에 객체로 만들 충분한 이유가 되고 이 객체 이름을 엔티티(Entity)라고 한다.

 

 

엔티티

  • 엔티티는 시스템의 내부 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화.
  • 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성. 
    [Clean Architecture] UML클래스로 표현한 Loan 엔티티
  • 핵심적인 개념을 구현하는 소프트웨어는 한데 모아 자동화 시스템의 나머지 모든 고려사항과 분리 시킨다.
    • 엔티티는 DB, UI, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 절대 안된다.
    • 업무의 대표자로서 독립적으로 존재해야 한다.

 

유스케이스

  • 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무규칙.
  • 즉, 자동화된 시스템이 사용되는 방법을 설명.
  • 수동환경에서는 사용될 수 없고, 오직 자동화된 시스템의 요소로 존재해야만 의미가 있다.
  • 엔티티 내부의 핵심 업무 규칙을 어떻게, 언제 호출할지를 명시하는 규칙을 담는다.
    • 애플리케이션에 특화된 규칙을 설명.
    • 사용자와 엔티티 사이의 상호작용을 규정.
  • UI와 유스케이스는 무관하다.
  • 엔티티(고수준)는 유스케이스(저수준)에 대해서 아무것도 알지 못한다.
    유스케이스는 엔티티에 대해서 알고있다.

유스케이스 객체의 구성요소

  • 애플리케이션에 특화된 업무 규칙을 구현하는 하나이상의 함수.
  • 입력데이터, 출력 데이터
  • 유스케이스가 상호작용하는 엔티티에 대한 참조 데이터.

 

 

결론

- 업무 규칙은 소프트웨어 시스템이 존재하는 이유이다. 업무 규칙은 핵심적인 기능이다.

- 업무 규칙은 UI나 DB와 같은 저수준의 관심사로 인해 오염되선 안되며, 원래 그대로의 모습으로 남아 있어야 한다.

- 업무 규칙은 시스템의 심장부에 위치해야하며, 덜 중요한 코드는 이 심장부에 플러그인 되어야한다.

- 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.