25장 - 계층과 경계

세 가지 컴포넌트의 클린 아키텍처?

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

이런 맥락이라면 클린 아키텍처 접근법을 적용하여 유스 케이스, 경계, 엔티티, 그리고 관련된 데이터 구조를 만드는 일도 쉬운 일입니다.

 

하지만 텍스트를 주고받은 메커니즘을 다양하게 만들고 싶을 수 있습니다.

sheel 창 또는 텍스트 메시지 또는 채팅 애플리케이션을 사용하기를 원할 수 있습니다.

따라서 언어를 통신 매커니즘으로부터 격리하는 API를 생성해야 할 수도 있습니다.

 

다이어그램은 복잡해질 수 있지만 점선으로 된 테두리는 API를 정의하는 추상 컴포넌트를 가리키며 위나 아래의 컴포넌트가 구현됩니다.

 

순전히 API 컴포넌트에만 집중한다면 다이어그램을 단순화할 수 있습니다.

 

GameRuls는 최상위 수준의 정책을 가지는 컴포넌트로 모든 화살표가 위를 향하도록 맞춰졌습니다.

 

1. 모든 입력은 사용자로부터 전달받아 TextDelivery 컴포넌트로 전달됩니다.

2. Language 컴포넌트를 거쳐 올라가, GameRules에 적합한 명령어로 번역됩니다.

3. GameRules는 사용자 입력을 처리하고 우측 하단의 DataStorage로 적절한 데이터를 흘려보냅니다.

4. 이후 GameRules를 Language로 출력을 돌려보내고 다시 TextDelivery를 통해 사용자에게 전달합니다.

 

이 구성을 통해 데이터 흐름을 두 개의 흐름으로 효과적으로 분리합니다.

 

그러면 데이터 흐름은 항상 두 가지일까요?

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

 

결론

콘 셸에서 단 200줄이면 구현할 수 있는 간단한 프로그램을 이처럼 정신없이 아키텍처 경계를 모두 추론해 내는 이유는 무엇일까요??

아키텍처 경계가 어디에나 존재한다는 사실을 보여주기 위함입니다.

 

오버 엔지니어링이 언더 엔지니어링보다 나쁠 때가 훨씬 많기 때문에 주의해야 합니다.