'런타임에 경계를 횡단한다'함은 그저 경계 한쪽에 있는 기능에서 반대편 기능을 호출하여 데이터를 전달하는 일에 불과하며 이 비결은 소스 코드 의존성 관리에 있다. 소스 코드가 변경되면 그에 관련된 모든 코드가 변경될 가능성이 있는데 이를 경계를 통해 변화의 전파를 막는 방화벽이 되어줄 수 있다.
아키텍처 경계에서 가장 단순한 형태는 코드가 나름의 규칙을 가지고 그냥 분리만 되어 있는것이다. 배포 관점에서는 이는 소위 "단일체"라고 불리는 단일 실행 파일에 지나지 않으며 C++과 C 프로젝트이거나, jar 파일로 묶인 자바 클래스 파일일 수도 있다. 배포 관점에서는 단일체의 경계가 드러나지 않지만 실제로는 존재한다. 다양한 컴포넌트들을 컴포넌트 단위로 분리하고 독립적으로 수행할 수 있게 하는 일은 굉장히 가치있는 일이다. 이 때문에 객체 지향 개발은 아주 중요한 패러다임이 되었으며 다형성이 없었다면 결합도 분리를 위해서 이전에 사용하던 포인터를 사용 해야 했을 것이다.
저수준 클라이언트에서 고수준 서비스로 향하는 함수 호출이다. 이 경우는 런타임 의존성과 컴파일타임 의존성은 모두 같은 방향, 즉 저수준 컴포넌트에서 고수준 컴포넌트로 향한다.
아래 그림을 확인해보자.
확인해보면 왼쪽에서 오른쪽으로 경계를 횡단하는 것을 확인할 수 있다.
Data는 호출되는 위치이다.
고수준 클라이언트가 저수준 서비스를 호출해야 하는 경우에는 동적 다형성(인터페이스)를 이용하여 제어를 역전시킬 수 있다.
위 그림을 보면 고수준의 클라이언트는 Service인터페이스를 통해서 저수준인 ServiceImpl의 f 함수를 호출하지만 경계를 횡단하는 순간은 왼쪽에서 오른쪽으로 감을 알 수 있다.
설령 모노리틱 구조의 실행 파일 이더라도 이처럼 규칙적인 방식으로 구조를 분리하면, 각 팀이 자신의 기능을 개발할 때 서로 영향을 끼치지 않고 독립적으로 작업이 가능하다.
고수준의 컴포넌트로 향하게 된다면 저수준 컴포넌트의 세부사항에 독립적으로 유지가 가능하다.
컴포넌트로 분리하더라도 같은 서버 내에서는 함수 호출에 불과하기 때문에 성능상 문제도 없다.
아키텍처의 경계가 물리적으로 들어날 수도 있는데 .jar, 루피 젬, 유닉스 공유 라이브러리 등이 그 예이다. 컴포넌트를 이 형태로 배포하면 따로 컴파일이 필요가 없다. 배포를 하는 작업은 단순히 이들을 배포 가능한 단위를 더 편하게 묶는 일에 지나지 않는다. (예를 들어 WAR 파일이나 심지어 그냥 디렉터리 형태로 묶기도 한다.)
이러한 배포 과정에서만 차이가 날 뿐 파일로 분리된 컴포넌트 형태와 큰 차이가 없다.
단일체와 배포형 컴포넌트는 모두 스레드를 활용할 수 있는데, 스레드는 아키텍처 경계도 아니고 배포 단위도 아니다. 단순히 실행 계획과 순서를 체계화 하는 방법에 가깝다.
- 강한 물리적 형태를 띠는 아키텍처 경계이다.
- 주로 명령행이나 그와 유사한 시스템 호출을 통해 생성된다.
- 소켓, 메일박스, 메세지 큐와 같은 운영체제에서 제공하는 통신 기술을 사용하여 서로 통신한다.
- 로컬 프로세스는 프로세스여서 메모리에 각각 독립된 실행 공간에 실행된다.
- 로컬 프로세스 또한 단일체나 바이너리 컴포넌트의 분리전략과 동일한데 항상 고수준 컴포넌트를 향한다.
- 따라서 로컬 프로세스에서는 고수준 프로세스의 소스 코드가 저수준 프로세스의 이름, 물리주소 등을 절대로 포함해서는 안된다.
물리적인 형태를 띠는 가장 강력한 경계이다. 서로 통신하는 두 서비스는 물리적으로 동일한 프로세스거나 다른 코어의 프로세스에서 동작할 수도 있지만 서비스들 사이에 모든 통신은 네트워크를 통해 이뤄진다고 가정한다. 따라서 호출은 매우 느리며 지연에 따른 별도 전략이 필요하다. 이를 제외하고는 로컬 프로세스에 적용된 규칙이 그대로 적용된다. 고수준 프로세스의 소스 코드가 저수준 프로세스의 이름, 물리주소 등을 절대로 포함해서는 안된다.(URL 등의 정보)