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

25장 계층과 경계

움퍼스 사냥 게임

소스 코드 의존성을 적절히 관리하면, UI 컴포넌트가 어떤 언어를 사용하더라도 게임 규칙을 재사용할 수 있다.
세부사항을 알지 않기를 바란다.
 

클린아키텍처?

변경의 축에 의해 정의되는 아키텍처 경계가 잠재되어 있을 수도 있다. 해당 경계를 가로지르는, 그래서 언어를 통신 메커니즘으로부터 격리하려는 API를 생성해야 할 수도 있다.
 

흐름 횡단하기

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

흐름 분리하기

상단의 단일 컴포넌트에서 서로 만단다고 생각할 수도 있다. 현실은 훨씬 복잡하다.
GameRules 컴포넌트 보다 더 높은 수준에는 또 다른 정책 집합이 존재한다.
저수준메커니즘과 관련된 정책에서는 이러한 고수준 정책에게 사건이 발생했음을 알린다.
고수준 정책에서는 플레이어의 상태를 관리한다.
 

결론

아키텍처 경계가 어디에나 존재한다는 사실
아키텍트로서 우리는 아키텍처 경계가 언제 필요한지를 신중하게 파악해내야 한다.
또한 우리는 이러한 경계를 제대로 구현하려면 비용이 많이 든다는 사실도 인지하고 있어야 한다.
 

26장 메인 컴포넌트

궁극적인 세부사항

메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다.
메인은 모든 팩토리와 전략 그리고 시스템 전반을 담당하는 나머지 기반 설비를 생성한 후, 시스템에서 더 높은 수준을 담당하는 부분으로 제어권을 넘기는 역할을 맡는다.
 
여러가지 내용을 main 함수에서 모두 처리하지만, 명령어를 실제로 처리하는 일은 다른 고수준 컴포넌트로 위임한다는 사실이다.
 

결론

메인은 초기 조건과 설정을 구성하고 외부 자원을 모두 수집한 후 제어권을 애플리케이션의 고수준 정책으로 넘기는 플러그인이다.
 

27장 크고 작은 모든 서비스들

서비스 아키텍처?

서비스도 마찬가지다. 결국 서비스는 프로세스나 플랫폼 경계를 가로지르는 함수 호출에 지나지 않는다. 아키텍처적으로 중요한 서비스도 있지만, 중요하지 않은 서비스도 존재한다.
이 장에서 우리가 관심을 가지는 서비스는 전자다.
 

서비스의 이점?

결합 분리의 오류
시스템을 서비스들로 분리함으로써 얻게 되리라 예상되는 큰 이점 하나는 서비스 사이의 결합이 확실히 분리된다는 점이다.
공유 자원 때문에 결합될 가능성이 여전히 존재한다.
서로 공유하는 데이터에 의해 이들 서비스는 강력하게 결합되어 버린다.
 
서비스들은 이 데이터 레코드에 강하게 결합되고, 서비스들 사이는 서로 간접적으로 결합되어 버린다.
 
개발 및 배포 독립성의 오류
서비스를 사용함에 따라서 예측되는 또 다른 이점은 전담팀이 서비스를 소유하고 운영한다는 점이다.
서비스는 확장가능한 시스템을 구축하는 유일한 선택지가 아니다.
 

야옹이 문제

이 서비스들은 모두 결합되어 있어서 독립적으로 개발하고, 배포하거나, 유지될 수 없다.
이게 횡단 관심사가 지닌 문제다.
 

객체가 구출하다.

컴포넌트 기반 아키텍처에는 이 문제를 어떻게 해결했을까? SOLID 설계 원칙을 잘 들여다보면, 다형적으로 확장할 수 있는 클래스 집합을 생성해서 새로운 기능을 처리하도록 함을 알 수 있다.
템플릿 메서드, 전략 패턴을 이용해서 오버라이드
야옹이 기능을 위해 UI변경은 어쩔 수 없지만, 런타임에 동적 로드하면 된다.
 

컴포넌트 기반 서비스

서비스는 SOLID 원칙대로 설계할 수 있으며 컴포넌트 구조를 갖출 수도 있다. 이를 통해 서비스 내의 기존 컴포넌트들을 변경하지 않고도 새로운 컴포넌트를 추가할 수 있다.
 

결론

서비스는 시스템의 확장성과 개발 가능성 측면에서 유용하지만, 그 자체로는 아키텍처적으로 그리 중요한 요소는 아니다.
서비스는 단 하나의 아키텍처 경계로 둘러싸인 단일 컴포넌트로 만들 수 있다. 혹은 여러 아키텍처 경계로 분리된 다수 컴포넌트로 구성할 수도 있다.
 

28장 테스트 경계

시스템 컴포넌트인 테스트

테스트는 아키텍처적으로 모두 동등하다.
테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다.
테스트는 독립적으로 배포 가능하다.
테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다.
 

테스트를 고려한 설계

테스트가 시스템의 설계와 잘 통합되지 않으면, 테스트는 깨지기 쉬워지고, 시스템은 뻣뻣해져서 변경하기가 어려워진다.
시스템의 공통 컴포넌트가 변경되면 수백 심지어 수천개의 테스트가 망가진다.
깨지기 쉬운 테스트 문제
 
시스템에 가한 간단한 변경이 대량의 테스트 실패로 이어진다는 사실을 알게 되면, 개발자는 그러한 변경을 하지 않으려 들 것이다.
 

테스트 API

구조적 결합
따로따로 진화할 수 있다는 점은 필수적인데, 시간이 지날수록 테스트는 계속해서 더 구체적이고 더 특화된 형태로 변할 것이고, 반대로 사용 코드는 더 추상적이고 더 범용적인 형태로 변할 것이기 때문이다.
 

결론

테스트를 시스템의 일부로 설계하지 않으면 테스트는 깨지기 쉽고 유지보수 하기 어려워지는 경향이 있다. 이러한 테스트는 유지보수하기가 너무 힘들기 때무에 결국 방바닥의 휴지처럼 버려지는 최후를 맡는다.
 

29장 클린 임베디드 아키텍처

소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다.
SQL을 심어놓거나 업무로직을 API로부터 분리하지 않는다면 펌웨어를 작성하는 셈이다.
 
펌웨어를 수없이 양산하는 일을 멈추고, 코드에게 유효 수명을 길게 늘릴 수 있는 기회를 주어라.
 

앱-티튜드 테스트

켄트백

• 먼저 동작하게 만들어라
• 그리고 올바르게 만들어라
• 그리고 빠르게 만들어라

앱이 동작하도록 만드는 것을 저자는 앱-티튜드 테스트라고 부른다.
예제에서 함수 목록을 분리하다가 특정 임베디드 장치에서만 테스트 할 수 있음을 발견
이 코드는 유효 수명을 길게 유지할 길이 아예 없어 보였다.
동작하고 테스트가 통과했다고 해서 클린 임베디드 아키텍처를 갖는다고 보기는 어렵다.
 

타깃-하드웨어 병목현상

임베디드 코드가 클린 아키텍처 원칙과 실천법을 따르지 않고 작성된다면 테스트 환경이 특정 타깃으로 국한될 것이다.
 
한 모듈이 다른 모듈에 대해 어디까지 알게 할지 신중하게 처리하지 않는다면 완성된 코드는 변경하기가 매우 어렵게 된다.
소프트웨어와 펌웨어가 서로 섞이는 일은 안티 패턴이다. 안티 패턴을 보이는 코드는 변화에 저항하게 된다.
 
펌웨어 <-> 소프트웨어 중간계층인 HAL을 둬서 소프트웨어에서 세부사항을 알지 못하게 한다.
 
프로세서 제작 업체가 제공하는 C 컴퍼일러는 프로세서 관련 나머지 함수들에 직접 접근할 수 있도록 해준다.
프로세서가 제공하는 확장기능을 사용하는 코드는 더 이상 C코드가 아니라는 사실을 인식해야한다.
 
애크미사의 DSP 제품군용 예제
IE, SBUF0, TI_0
등은 편리한 기능이다. 하지만 이 코드는 C가 아니다.
펌웨어가 저수준 함수들을 PAL의 형태로 격리시켜줄 수 있다.
 
소프트웨어는 운영체제를 통해 운영 환경이 제공하는 서비스에 접근한다.
OS를 직접 사용하면 문제가 된다.
OS가 달라진다면 수 많은 코드를 변경해야 할 것이다.
OSAL 중간계층을 넣어서 세부사항을 모르게한다.
코드 비대화 문제가 염려
 
오직 구현체에서만 필요 데이터 구조, 상수 타입 정의들로 인터페이스 헤더 파일을 어지럽히지 말라.
원치 않는 의존성을 만들어 낼 것이다.
세부사항을 알고 있는 부분이 적을 수록 추적하고 변경해야 할 코드도 적어진다.
 

결론

클린 임베디드 아키텍처는 제품이 장시간 생명력을 유지하는 데 도움을 준다.