애플리케이션을 업무 규칙과 플러그인으로 구분하려면 업무 규칙이 실제로 무엇인지를 잘 이해해야만 한다.

핵심 업무 규칙(Critical Business Rule)

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

핵심 업무 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그대로 존재한다.

핵심 업무 데이터

• 핵심 업무 규칙이 요구하는 데이터
• 시스템으로 자동화되지 않은 경우에도 존재하는 데이터이다.

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

엔티티

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

• 핵심 업무 데이터를 직접 포함할 수 있다.
• 핵심 업무 데이터에 매우 쉽게 접근할 수 있다.

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

엔티티를 생성할 때는

• 업무에서 핵심적인 개념을 구현하는 소프트웨어를 한데 모은다.
• 구축 중인 자동화 시스템의 나머지 모든 고려사항과 분리시킨다.

이 클래스는 업무의 대표자로서 독립적으로 존재한다.

엔티티는 순전히 업무만을 위한 것이므로 데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 절대 안된다.

• 어떤 시스템에서도 업무를 수행할 수 있어야 한다.
• 시스템의 표현 형식이나 데이터 저장 방식, 시스템에서 컴퓨터가 배치되는 방식과도 무관하다.

엔티티의 유일한 요구 조건은 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어 별도의 소프트웨어 모듈로 만들어야 한다는 것이다.

유스케이스

유스케이스는 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무 규칙이다.

• 자동화된 시스템이 사용되는 방법을 설명한다.
• 사용자가 제공해야 하는 입력을 기술한다.
• 사용자에게 제공해야하는 출력을 기술한다.
• 해당 출력을 생성하기 위한 처리 단계를 기술한다.

엔티티 내의 핵심 업무 규칙과는 반대로, 애플리케이션에 특화된 업무 규칙을 설명한다.

인터페이스로 들어오는 데이터와 인터페이스에서 도될려주는 데이터를 형식 없이 명시한다는 점만 빼면, 유스케이스는 사용자 인터페이스를 기술하지 않는다.

유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다.

애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정한다.

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

유스케이스는 단일 애플리케이션에 특화되어 있으며, 따라서 해당 시스템의 입력과 출력에 보다 가깝게 위치하므로, 엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무것도 알지 못한다.

즉, 유스케이스는 엔티티에 의존하며, 엔티티는 유스케이스에 의존하지 않는다.

요청 및 응답 모델

유스케이스는 입력 데이터를 받아서 출력 데이터를 생성한다.

하지만 제대로 구성된 유스 케이스 객체라면 데이터를 사용자나 또 다른 컴포넌트와 주고 받는 방식에 대해서는 전혀 눈치챌 수 없어야 한다.

유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고 단순한 응답 데이터 구조를 출력으로 반환하는 역할만 수행하며, 이러한 데이터 구조는 어떤것에도 의존하지 않아야 한다.

• HttpRequest, HttpResponse 등

요청 및 응답 모델이 독립적이지 않다면 그 모델에 의존하는 유스케이스도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합이 되므로 의존성을 제거해야 한다.

엔티티와 요청/응답 모델은 많은 데이터를 공유하므로 엔티티의 참조를 요청/응답 데이터 구조에 포함하려는 유혹을 받을 수 있다.

하지만 두 객체의 목적은 완전히 다르므로, 시간이 지남에 따라 다른 이유로 변경될 것이다.

따라서 어떤 식으로든 함께 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 되며, 결국 코드에는 수많은 떠돌이 데이터가 만들어지고, 이로인해 수많은 조건문이 추가되어 버린다.

결론

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

업무 규칙은 수익을 내고 비용을 줄이는 코드를 수반하는 매우 중요한 요소이다.

따라서 사용자 인터페이스나 데이터베이스와 같은 저수준의 관심사로 인해 오염되어서는 안 되며, 원래 그대로의 모습으로 남아 있어야 한다.

이상적으로는 업무 규칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야 하며, 덜 중요한 코드는 이 심장부에 플러그인되어야 한다.

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