[Book]Clean Architecture 5부(20~24장)

업무 규칙

• 업무 규칙은 사업적으로 수익을 내거나 비용을 줄일 수 있어야 한다. 심지어 사람이 수동으로 직접 수행하더라도 마찬가지다.
• 이러한 규칙을 핵심 업무 규칙(Critical Bussiness Rule)이라고 부를 것이다. 이들 규칙은 사업 자체에 핵심적이며, 규칙을 자동화하는 시스템이 없더라도 업무 규칙은 그대로 존재하기 때문이다.
• 핵심 업무 규칙에는 데이터가 필요하며, 이 데이터를 핵심 업무 데이터라고 부른다.

엔티티

• 엔티티는 컴퓨터 시스템 내부의 객체로서, 핵심 업무 데이터를 기반으로 동작하는 일련의 조그만 핵심 업무 규칙을 구체화한다.
• 엔티티 객체는 핵심 업무 데이터를 직접 포함하거나 핵심 업무 데이터에 매우 쉽게 접근할 수 있다.
• 엔티티의 인터페이스는 핵심 업무 데이터를 기반으로 동작하는 핵심 업무 규칙을 구현한 함수들로 구성한다.

유스케이스(UseCase)

• 자동화된 시스템이 동작하는 방법을 정의하고 제약함으로써 수익을 얻거나 비용을 줄이는 업무규칙도 존재한다. 이러한 규칙은 자동화된 시스템의 요소로 존재해야만 의미가 있으므로 수동 환경에서는 사용될 수 없다.
• 유스케이스는 시스템이 사용자에게 어떻게 보이는지를 설명하지 않는다. 이보다는 애플리케이션에 특화된 규칙을 설명하며, 이를 통해 사용자와 엔티티 사이의 상호작용을 규정한다. 시스템에서 데이터가 들어오고 나가는 방식은 유스케이스와 무관하다.

요청 및 응답 모델

• 엔티티와 요청/응답 모델을 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배한다.

결론

• 업무 규칙은 SW시스템이 존재하는 이유다.
• 업무 규칙은 핵심적인 기능이다.
• 업무 규칙은 수익을 내고 비용을 줄이는 코드를 수반한다.
• 업무 규칙은 사용자 인터페이스나 DB와 같은 저수준의 관심사로 인해 오염되어서는 안되며, 원래 그대로의 모습으로 남아 있어야 한다.
• 이상적으로는 업무 규칙을 표현하는 코드는 반드시 시스템의 심장부에 위치해야하며, 덜 중요한 코드는 이 심장부에 플러그인되어야 한다.
• 업무 규칙은 시스템에서 가장 독립적이며 가장 많이 재사용할 수 있는 코드여야 한다.

소리치는 아키텍쳐

아키텍처의 목적

• 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다.
• 좋은 아키텍처는 개발 환경 문제나 도구에 대한 결정을 미룰 수 있게 해주며, 이러한 결정을 쉽게 번복할 수 있도록 한다.
• 좋은 아키텍처는 유스케이스를 중점에 두며, 지엽적인 관심사에 대한 결합은 분리시킨다.

하지만 웹은?

• 웹은 아키텍처일까? 당연히 아니다! 웹은 전달 매커니즘이며, 애플리케이션 아키텍처에서도 그와 같이 다뤄야 한다.

프레임워크는 도구일뿐, 삶의 방식은 아니다.

• 프레임워크는 도움이 되겠지만, 어떻게 사용할지, 그리고 사용하지 않으려면 어떻게 해야할지를 스스로에게 물어보라.
• 어떻게 하면 유스케이스에 중점을 둔 채 그대로 보존할 수 있을지를 생각하라.
• 프레임워크가 아키텍처의 중심을 차지하는 일을 막을 수 있는 전략을 개발하라.

테스트하기 쉬운 아키텍처

• 프레임워크를 전혀 준비하지 않더라도 필요한 유스케이스 전부에 대해 단위 테스트를 할 수 있어야 한다.

결론

• 아키텍처는 시스템을 이야기해야하며, 시스템에 적용한 프레임워크에 대해 이야기해서는 안된다.

클린 아키텍처

• 프레임워크 독립성 : 아키텍처는 다양한 기능의 라이브러리를 제공하는 SW, 즉 프레임워크의 존재여부에 의존하지 않는다.
• 테스트 용이성 : 업무 규칙은 UI, DB, 웹 서버, 외부요소가 없이도 테스트 할 수 있다.
• UI 독립성 : 시스템의 나머지 부분을 변경하지 않고도 UI를 쉽게 변경할 수 있다.
• 데이터베이스 독립성 : 오라클이나 mySql서버를 몽고DB, 빅테이블, 카우치DB등으로 교체할 수 있다. 업무 규칙은 데이터베이스에 결합되지 않는다.
• 모든 외부 에이전시에 대한 독립성 : 실제로 업무 규칙은 외부 세계와의 인터페이스에 대해 전혀 알지 못한다.

프레젠터와 험블객체

• 프레젠터는 험블객체패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는데 도움이 된다.

험블객체패턴

• 험블객체패턴은 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다.
• 행위들을 두 개의 모듈 또는 클래스로 나눈다. 모듈 중 하나가 험블이다. 가장 기본적인 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다. 나머지 모듈에는 험블객체에 속하지 않은 테스트하기 쉬운 행위를 모두 옮긴다.
• 험블객체패턴을 사용하면 두 부류의 행위를 분리하여 프레젠터와 뷰라는 서로 다른 클래스를 만들 수 있다.

프레젠터와 뷰

• 뷰는 험블객체이고 테스트하기 어렵다. 이 객체에 포함된 코드는 가능한 간단하게 유지한다. 뷰는 데이터를 GUI로 이동시키지만, 데이터를 직접 처리하지는 않는다.
• 프레젠터는 테스트하기 쉬운 객체다. 프레젠터의 역할은 애플리케이션으로부터 데이터를 받아 화면에 표현할 수 있는 포맷으로 만드는 것이다. 이를 통해 뷰는 데이터를 화면으로 전달하는 간단한 일만 처리하도록 한다.

테스트와 아키텍처

• 테스트하기 쉬운 부분과 어려운 부분을 분리하면, 아키텍처의 경계가 되는데, 프레젠터와 뷰 사이의 경계는 이러한 경계 중 하나이다.

부분적 경계

• 아키텍처 경계를 만드는 비용이 너무 크다고 판단하면서도, 나중에 필요할 수 있으므로 경계에 필요한 공간을 확보하기 원할 수 있다.
• 이때, 부분적 경계를 구현해볼 수 있으며, 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업을 수행 후 단일 컴포넌트에 모아만 두는 것이다.

퍼사드

• 퍼사드 클래스는 모든 서비스 클래스를 메서드 형태로 정의하고, 서비스 호출이 발생하면 해당 서비스 클래스로 호출을 전달한다. 클라이언트는 이들 서비스 클래스에 직접 접근할 수 없다.