18장. 경계해부학

이해가 되지 않아 일단 내용 정리식으로 작성하였습니다.

경계 횡단하기

• 런타임에 경계를 횡단한다.
• 한쪽 경계에 있는 기능이 반대편 기능을 호출하여 데이터를 전달하는 일

• 소스 코드가 변경되면 의존하는 다른 소스 코드들도 변경,컴파일이 필요할 수 있다.

• 그렇기 때문에 소스 코드 의존성 관리를 통해 적절한 위치에서 경계를 횡단하게 해야 한다.

• 경계는 이러한 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단으로 존재한다.

두려운 단일체

소스 수준 분리 모드 (p.165) : 모노리틱 구조

• 배포 관점에서는 경계가 들어나지 않는다.
• 하나의 커다란 jar 파일과도 같으니깐

• 특정한 동적 다형성에 의존하여 내부 의존성을 관리한다.
• DI와 같은 방식을 말하는 듯 합니다.
 

저수준이 고수준에 의존한다.

저수준 클라이언트 → 고수준 서비스

• 런타임 의존성과 컴파일타임 의존성은 모두 같은 방향
• 저수준 컴포넌트에서 고수준 컴포넌트로 향한다.

• 제어흐름이 왼쪽에서 오른쪽으로 경계를 횡단한다.

• 경계에서 호출되는 쪽에 Data에 대한 정의가 위치한다.

고수준 클라이언트 ← 저수준 서비스

• 동적 다형성을 사용하여 제어흐름과는 반대 방향으로 의존성을 역전
• 런타임 의존성은 컴파일타임 의존성과는 반대가 된다.

• 제어 흐름의 경우 앞썬 예제와 동일하게 왼쪽에서 오른쪽으로 경계를 횡단한다.
• 하지만 경계를 횡단할 때 의존성은 모두 오른쪽에서 왼쪽 즉, 고수준 컴포넌트를 향한다.
• 또한, 데이터 구조의 정의가 호출하는 쪽에 위치한다.

모노리틱 구조라도 위처럼 규칙적인 방식으로 구조를 분리하게 되면 개발, 테스트, 배포하는 작업에 큰 도움을 주며 고수준 컴포넌트는 저수준 세부사항으로부터 독립적으로 유지될 수 있다.

• 소스 수준에서 결합이 분리되면 경계를 가로지르는 통신은 상당히 빈번할 수 있다. (단일체에서 컴포넌트 간 통신은 매우 빠르고 값싸기 때문에)

배포형 컴포넌트

배포 수준 결합 분리 모드

• 아키텍처의 경계가 물리적으로 들어날 수 있다.
• 동적 링크 라이브러리

• 배포 과정에서만 차이가 날뿐, 배포 수준의 컴포넌트는 단일체와 동일하다.

로컬 프로세스

• 훨씬 강한 물리적 형태를 띠는 아키텍처 경계

• 주로 명령행이나 그와 유사한 시스템 호출을 통해 생성

• 각각이 독립된 주소 공간에서 실행

• 각 로컬 프로세스는 정적으로 링크된 단일체거나 동적으로 링크된 여러개의 컴포넌트로 구성될 수 있다.

• 로컬 프로세스를 일종의 최상위 컴포넌트로 생각한다면 컴포넌트 간 의존성을 동적 다형성을 통해 관리하는 저수준 컴포넌트로 구성된다.
• 그렇기 때문에 고수준 프로세스의 소스 코드가 저수준 프로세스의 정보를 포함해서는 안된다. (프로세스의 이름, 물리 주소, 레지스트리 조회 키)
• 메모리 공유가 되지 않으므로 통신은 운영체제 호출, 데이터 마샬링 및 언마샬링, 프로세스 간 문맥 교환 등 비싼 작업이므로 통신이 너무 빈번하게 이뤄지지 않도록 신중하게 제한해야 한다.

서비스

• 물리적인 형태를 띠는 가장 강력한 경계

• 자신의 물리적 위치에 구애받지 않는다.
• 모든 통신이 네트워크를 통해 이뤄진다.

• 서비스 경계를 지나는 통신은 함수 호출에 비해 매우 느리기 때문에 빈번하게 통신하는 일은 피해야 한다.

• 이 수준의 통신 지연에 따른 문제를 고수준에서 처리할 수 있어야 한다.

• 로컬 프로세스에 적용한 규칙이 그대로 적용된다.
• 고수준 서비스의 소스 코드에는 저수준 서비스를 특정 짓는 어떤 물리적인 정보도 포함해서는 안된다. (URI)

결론

• 단일체를 제외한 대다수의 시스템은 한 가지 이상의 경계 전략을 사용한다.

• 개별 서비스, 로컬 프로세스는 소스 코드 컴포넌트로 구성된 단일체이거나, 동적으로 링크된 배포형 컴포넌트의 집합이다.

• 즉, 대체로 한 시스템 안에서도 통신이 빈번한 로컬 경계와 지연을 중요하게 고려해야 하는 경계가 혼합되어 있음을 의미한다.