업무 규칙

업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 엄밀하게 말하자면 컴퓨터 상으로 구현했는지와 상관없이, 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다.

대출에 N%의 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙이다. 이러한 사실은 컴퓨터 프로그램으로 이자를 계산하든, 또는 직원이 주판을 튕겨 계산하든 하등의 관계가 없다.

이러한 규칙을 핵심 업무 규칙(Critical Business Rule) 이라고 한다. 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 존재하기 때문이다.

핵심 업무 규칙은 보통 데이터를 필요로한다. 예를 들어 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다. 이러한 데이터를 핵심 업무 데이터(Critical Business Data) 라고 하겠다.

핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다. 우리는 이러한 유형의 객체를 엔티티(Entity) 라고 하겠다.

엔티티

엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화한다.

엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성된다.

이러한 종류의 클래스를 생성할 때, 업무에서 핵심적인 개념을 구현하는 소프트웨어는 한데 모으고, 구축 중인 자동화 시스템의 나머지모든 고려사항과 분리시킨다. 즉 DB, UI, 서드파티 프레임워크에 대한 고려사항들로 오염되어서는 절대 안 된다. 엔티티는 순전히 업무에 대한 것이며, 이 외의 것은 없다.

꼭 클래스가 아니어도 된다. 유일한 요구조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어서 별도의 소프트웨어 모듈로 만들어야 한다는 것이다.

유스케이스

모든 업무 규칙이 엔티티처럼 순수한 것은 아니다.

예를 들어 은행 직원이 신규 대출을 생성하는 것을 생각해보자. 대출 담당자가 신청자의 신상정보를 수집하여 검증한 후, 신용도가 500보다 낮다면 대출 견적을 제공하지 않기로 결정했다고 해보자. 시스템은 신상정보 폼을 채우고 검증한 후, 신용도를 체크한 뒤에 대출 견적 화면으로 넘어가야할 것이다.

이게 유스케이스(usecase)이다. 유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 해당 출력을 생성하기 위한 처리 단계를 기술한다. 엔티티 내의 핵심 업무 규칙과는 반대로, 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명한다.

유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담는다. 하지만 유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다. 단지 사용자와 엔티티 사이의 상호작용을 규정한다.

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

엔티티는 자신을 제어하는 유스케이스에 대해서는 아무 것도 알지 못한다. 엔티티가 고수준이고 유스케이스는 상대적으로 저수준이며 유스케이스는 엔티티에 의존하지만 엔티티는 유스케이스에 의존하지 않는다.

요청 및 응답 모델

유스케이스는 입력 데이터를 받아서 출력 데이터를 생성한다. 유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고, 단순한 응답 데이터 구조를 출력으로 반환한다.

데이터 구조는 어느 것에도 의존하지 않는다. 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스도결국 해당 모델이 수반하는 의존성에 간접적으로 결합된다.

결론

업무 규칙은 소프트웨어 시스템이 존재하는 이유다. 업무 규칙은 UI나 DB와 같은 저수준의 관심사로 인해 오염되어서는 안 되며, 원래 그대로의 모습으로 남아 있어야 한다.

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