클린 아키텍처 - 5부 : 아키텍처 (2/3)

20장 업무 규칙

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

업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다.

핵심 업무 규칙 - 사업 자체에 핵심적, 보통 데이터를 요구

이에 필요한 데이터를 핵심 업무 데이터라 한다.

핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다.

이러한 유형을 객체 엔티티

엔티티

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

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

유스케이스

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

유스케이스는 애플리케이션에 특화된 업무 규칙을 설명한다.

유스케이스는 엔티티 내부의 핵심 업무 규칙을 어떻게, 그리고 언제 호출할지를 명시하는 규칙을 담는다.

유스케이스만 봐서는 이 애플리케이션이 웹을 통해 전달되는지, 리치 클라이언트인지, 콘솔 기반인지 아니면 순수한 서비스인지 구분하기 불가능하다.

엔티티는 고수준, 유스케이스는 저수준

유스케이스는 단일 애플리케이션에 특화

엔티티는 다양한 애플리케이션에서 사용될 수 있도록 일반화 된 것

 

요청 및 및 응답 모델

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

시간이 지나면 두 객체는 완전히 다른 이유로 변경될 것이고 두 객체를 함께 묶는 행위는 공통 폐쇄 원칙과 단일 책임 원칙을 위배하게 된다.

 

21장 소리치는 아키텍처

아키텍처만 보고도 어떠한 시스템인지 알 수 있게 구성해야 한다?

 

아키텍처의 테마

프레임워크는 사용하는 도구일뿐 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다.

 

아키텍처의 목적

좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다. ( 세부사항 선택 미루기, 회사에선 쉽지 않음 여러 명이서 제한된 시간내에 개발해야 하고, 보고도 해야하기 때문)

 

하지만 웹은?

웹은 전달 메커니즘이며, 웹으로 전달할지 여부는 미루어야 할 결정사항 중 하나다.

 

테스트하기 쉬운 아키텍처

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

엔티티 객체는 간단한 객체여야 하며, 복잡한 것들에 의존해서는 안 된다.

22장 클린 아키텍처

• 육각형 아키텍처
• DCI
• BCE

공통점은 관심사 분리

 

클린 아키텍처의 특징

• 프레임워크 독립성
• 테스트 용이성
• UI 독립성
• 데이터베이스 독립성
• 모든 외부 에이전시에 대한 독립성

의존성 규칙

소스 코드 의존성은 반드시 안쪽으로, 고수준의 정책을 향해야 한다.

외부의 원에 선언된 데이터 형식도 내부의 원에서 절대로 사용해서는 안 된다.

 

엔티티

엔티티는 전사적인 핵심 업무 규칙을 캡슐화한다.

외부의 무언가가 변경되더라도 엔티티가 변경될 가능성은 지극히 낮다.

 

유스케이스

유스케이스 계층의 소프트웨어는 애플리케이션에 특화된 업무 규칙을 포함한다. 또한 유스케이스 계층 시스템의 모든 유스케이스를 캡슐화하고 구현한다. 데이터 흐름을 조정

 

인터페이스 어댑터

프레젠터, 뷰, 컨트롤러는 모두 인터페이스 어댑터 계층에 속한다.

데이터를 외부 서비스와 같은 외부적인 형식에서 유스케이스나 엔티티에서 사용되는 내부적인 형식으로 변환하는 또 다른 어댑터가 필요하다.

 

프레임워크와 드라이버

프레임워크와 드라이버 계층은 모두 세부사항이 위치하는 곳이다.

 

원은 네 개여야만 하나?

항상 네 개만 사용해야 한다는 규칙은 없다. 어떤 경우에도 의존성 규칙은 적용된다.

 

경계 횡단하기

제어흐름과 의존성의 방향이 명백히 반대여야 하는 경우, 의존성 역전 워닉을 사용하여 해결한다.

인터페이스와 상속 광계를 적절하게 배치

 

경계를 횡단하는 데이터는 어떤 모습인가

경계를 가로질러 데이터를 전달할 때, 데이터는 항상 내부의 원에서 사용하기 가장 편리한 형태를 가져야만 한다.

 

전형적인 시나리오

모든 의존성은 경계선을 안쪽으로 가로지르며, 따라서 의존성 규칙을 준수한다.

23장 프레젠터와 험블 객체

험블 객체 패턴

행위들을 두 개의 모듈 또는 클래스로 나눈다. 본질은 남기고, 테스트하기 어려운 행위를 모두 험블 객체로 옮긴다.

데이터베이스 게이트웨이

유스케이스 인터렉터와 데이터베이스 사이에는 데이터베이스 게이트웨이가 위치한다.

유스케이스 계층은 SQL을 허용하지 않는다.

게이트웨이는 스텁이나 테스트 더블로 적당히 교체할 수 있기 때문이다.

 

데이터 매퍼

실제로 ORM은 게이트웨이 인터페이스와 데이터베이스 사이에서 일종의 또 다른 험블 객체 경계를 형성한다.

 

24장 부분적 경계

애자일 커뮤니티에서 선행적인 설계를 탐탁치 않게 여기는데, YAGNI 원칙을 위배하기 때문

 

마지막 단계를 건너뛰기

부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 커모넌트에 그대로 모아만 두는 것이다.

모두를 단일 컴포넌트로 컴파일해서 배포

많은 코드량과 사전 설계가 필요하다.

 

일차원 경계

완벽한 형태의 아키텍처 경계는 양방향으로 격리된 상태를 유지, 유지할 때도 비용이 많이 든다.

점선과 같은 비밀 통로가 생기는 일을 막을 방법이 없다.

 

파사드

모든 의존성을 파사드 클래스에 정의하고, 클라이언트가 파사드 클래스를 호출한다.

모든 서비스 클래스에 대해 추이 종석성을 갖게 된다.

 

경계가 언제, 어디에 존재해야 할지, 그리고 그 경계를 완벽하게 구현할지 아니면 부분저그로 구현할지 결정하는 일 또한 아키텍트의 역할이다.