‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆♂️
- 업무 규칙은 컴퓨터상으로 구현했는지와 무관하게 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다.
- ex. 대출에 N% 이자를 부과한다는 사실은 은행이 돈을 버는 업무 규칙이다.
- 이러한 사실은 컴퓨터 프로그램으로 이자를 계산하든, 또는 직원이 주판을 튕겨 계산하든 하등의 관계가 없다.
- 이러한 업무 규칙을
핵심 업무 규칙이라 부른다.- 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그대로 존재하기 때문이다.
- 핵심 업무 규칙은 보통 데이터를 요구하는데 이를
핵심 업무 데이터라 부른다.- 예를 들어, 대출에는 대출 잔액, 이자율, 지급 일정이 필요하다.
- 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 떄문에 객체로 만들 좋은 후보다. 이를 엔티티라 칭한다.
엔티티
- 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화한 객체다.
- 대출 엔티티를 UML클래스로 표현한 엔티티로 독립적으로 존재한다.
- 이 클래스는 핵심업무개념을 표현하며 DB, UI 등에 무관하게 존재한다.
- 엔티티는 꼭 객체 지향 언어로 구현할 필욘 없다.
- 핵심 업무 데이터와 핵심 업무 규칙을 하나로 묶어 별도 소프트웨어 모듈로 만들면 된다.
유스케이스
- 사용자가 제공해야 하는 입력, 사용자에게 보여줄 출력, 해당 출력을 생성하기 위한 처리 단계를 기술한다.
- 엔티티 내의 핵심 업무 규칙과는 반대로 유스케이스는 애플리케이션에 특화된 업무 규칙을 설명한다.
- 유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담는다.
- 유스케이스는 UI를 기술하지 않는다는점이 중요하다.
- 유스케이스만 봐선 웹을 통해 전달되는지, 콘솔 기반인지 구분할 수 없어야 한다.
- 즉, 애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정한다.
- 엔티티는 자신을 제어하는 유스케이스에 대해 아무것도 알지 못한다.
- 이는 DIP 를 준수하는 의존성 방향에 대한 또 다른 예다.
- 엔티티와 같은 고수준 개념은 유스케이스와 같은 저수준 개념에 대해 아무것도 알지 못한다.
- 반대로 저수준인 유스케이스는 고수준인 엔티티에 대해 알고 있다.
- 왜 엔티티는 고수준이며, 유스케이스는 저수준일까?
- 유스케이스는 단일 애플리케이션에 특화되어 있어 해당 시스템의 입출력과 가깝기 때문이다.
- 반대로 엔티티는 다양한 애플리케이션에 적용 가능하도록 일반화된 것이기에 더 멀다.
요청 및 응답 모델
- 제대로 구성된 유스케이스 객체라면 데이터를 사용자나 또 다른 컴포넌트와 주고 받는 방식에 대해 전혀 눈치챌 수 없어야 한다..
- 유스케이스 클래스의 코드가 HTML, SQL 에 대해 알게 되선 안된다.
- 유스케이스는 단순한 요청 데이터 구조를 독립적으로 받고, 단순한 응답 데이터 구조를 출력으로 반환한다.
- 웹에 대해서 알지 못하며 UI 에 종속되서도 안된다..
- 이처럼 의존성을 제거하는 것은 매우 중요하다.
- 요청 및 응답 모델이 독립적이지 않다면, 그 모델에 의존하는 유스케이스도 결국 해당 모델이 수반하는 의존성에 간접적으로 결합되어 버린다.
- 즉 엔티티와 RQ/RS 모델을 독립적으로 분리하라는게 핵심이다.
- 왜일까? 두 객체의 목적이 완전히 다르기에 시간이 지나면 두 객체는 완전히 다른 이유로 변경될 것이다.
- 따라서 두 객체를 어떤 식으로든 함께 묶는 행위는 공통 폐쇄 언칙과 단일 책임 원칙을 위반하게 된다.
- 결국 코드에는 수많은 떠돌이 데이터가 만들어지고, 수 많은 조건문이 추가될 것이다…
결론
- 업무 규칙은 UI나 DB와 같은 저수준 관심사로 인해 오염되선 안되며, 원래 그대로의 모습으로 남아있어야 한다.
- 이상적으로는 업무 귝칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야 하며, 덜 중요한 코드는 이 심장부에 플러그인되어야 한다.
- 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.