05 아키텍처 (6)

24장. 부분적 경계

완전한 아키텍처 경계를 만드는데는 비용이 많이 든다.

또한 선행적으로 설계하기에는 YAGIN(You Aren't Going to Need It) 원칙을 위배한다.

그럼에도 불구하고 미리 만들어두길 원한다면 부분적 경계를 구현해 볼 수 있다.

마지막 단계를 건너뛰기

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

완벽한 경게를 만드 떄와 동일한 코드량과 사전 설계가 필요하지만, 다수의 컴포넌트를 관리하는 부담이 줄어든다.

일차원 경계

완병학 형태의 아키텍처 경계에서는 쌍방향 Boundary 인터페이스를 사용하지만, 비용이 많이 든다.

전략패턴을 사용하면 추후 완벽한 형태의 경계로 확장할 수 있는 공간을 확보할 수 있다.

Client를 ServiceImpl로부터 격리시키는데 필요한 의존성 역전을 미리 적용한다.

퍼사드

더욱 단순한 경계인 퍼사드 패턴은 의존성 역전까지도 희생한다.

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

 

하지만 client가 모든 서비스 클래스에 대해 추이 종속성을 가지게 된다.

---

25장. 계층과 경계

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다.

하지만 대다수의 시스템에서 컴포넌트 개수는 이보다 훨씬 많다.

움퍼스 사냥 게임

게임 규칙과 UI를 분리해서 여러 시장에 다양한 언어로 발매한다고 가정해보자.

소스 코드 의존성을 적절히 관리하면, UI 컴포넌트가 어떤 언어이든 게임 규칙을 재사용할 수 있다.

클린 아키텍처?

UI에서 언어가 유일한 변경의 축은 아니다. 변경의 축에 의해 정의되는 아키텍처 경계가 잠들어있을 수 있다.

English, SMS, CloudData와 같은 변형들은 추상 API 컴포넌트가 정의하는 다형적 인터페이스를 통해 제공되고, 실제로 서비스하는 구체 컴포넌트가 해당 인터페이스를 구현한다.

 

이러한 변형들을 모두 제거하고 순전히 API 컴포넌트만 집중하면 다이어그램을 단순화할 수 있다.

최상위에 GameRules가 놓이고, 데이터 흐름은 두 개의 흐름으로 나뉜다.

왼쪽의 흐름은 사용자와의 통신에 관여하며, 오른쪽의 흐름은 데이터 영속성에 관여한다.

시스템이 복잡해질수록 컴포넌트 구조는 더 많은 흐름으로 분리된다.