업무규칙 (Business rule)
엄밀하게 말하면 업무 규칙은 사업적으로 수익을 더거나 비용을 줄일 수 있는 규칙 또는 절차다.
업무 규칙은 보통 데이터를 요구하고 이러한 데이터를 업무 데이터라고 정의할 수 있다.
핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 Entity 객체로 만들 수 있다.
엔티티
엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구체화한다.
엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성된다.
엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못한다.
e.g. Loan 엔티티
이 클래스는 독립적으로 존재하고, 데이터베이스, 사용자 인터페이스, 서드파티 프레임워크에 대한 고려사항들로 인해 오염되어서는 안된다.
유스케이스
유스케이스는 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 해당 출력을 생성하기 위한 처리 단계를 기술한다.
엔티티 내의 핵심 업무 규칙과는 다르게, 애플리케이션에 특화된 업무 규칙을 설명한다.
유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 언제 호출할지를 명시하는 규칙을 담는다.
유스케이스는 시스템이 사용자에게 어떻게 보이는지 설명하지 않는다. 사용자와 엔티티 사이의 상호작용을 규정한다.
요청 및 응답 모델
유스케이스 객체는 데이터를 사용자나 다른 컴포넌트와 주고받는 방식에 대해서는 눈치챌 수 없어야 한다.
유스케이스는 단순한 요청 데이터 구조를 입력으로 받아들이고 단순한 응답 데이터 구조를 출력으로 반환한다.
결론
업무 규칙은 소프트웨어 시스템이 존재하는 이유이다. 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.
소리치는 아키텍처
소프트웨어 애플리케이션의 아키텍처도 애플리케이션의 유스케이스에 대해 소리쳐야 한다.
아키텍처의 목적
- 좋은 아키텍처는 유스케이스를 중심에 두기 때문에, 프레임워크나 도구, 환경에 구애받지 않고 유스케이스를 지원하는 구조를 문제없이 기술할 수 있다.
- 좋은 아키텍처는 프레임워크, 데이터베이스, 웹 서버 등 개발 환경에 대한 결정을 미룰 수 있도록 만든다.
테스트하기 쉬운 아키텍처
아키텍처가 유스케이스를 최우선으로 한다면, 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다. 프레임워크로 인한 어려움을 겪지 않고도 반드시 모두를 테스트할 수 있어야 한다.
결론
아키텍처는 시스템을 이야기해야 하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안 된다. 새로 합류한 프로그래머는 시스템이 어떻게 전달될지 알지 못한 상태에서도 시스템의 모든 유스케이스를 이해할 수 있어야 한다.
Reference
Clean Architecture - Robert C. Martin
