18. 경계 해부학 요약

시스템 아키텍처는 일련의 소프트웨어 컴포넌트와 그 컴포넌트들을 분리하는 경계에 의해 정의된다.

경계 횡단하기

• '런타임에 경계를 횡단한다' 함은 그저 경계 한쪽에 있는 기능에서 반대편 기능을 호출하여 데이터를 전달하는 일에 불과하다.
• 적절한 위치에서 경계를 횡단하게 하는 비결은 소스 코드 의존성 관리에 있다.
  • 소스 코드 모듈 하나가 변경되면, 이에 의존하는 다른 소스 코드 모듈도 변경하거나, 다시 컴파일해서 새로 배포해야 할지 모르기 때문이다.
  • 경계는 이러한 변경이 전파되는 것을 막는 방화벽을 구축하고 관리하는 수단으로써 존재한다.

두려운 단 일체

• 아키텍처 경계 중에서 가장 단순하며 가장 흔한 형태는 물리적으로 엄격하게 구분되지 않는 형태다.
  • 이 형태에서 함수와 데이터가 단일 프로세서에서 같은 주소 공간을 공유하며 그저 나름의 규칙에 따라 분리되어 있을 뿐이다. (소스 수준 분리 모드)
• 배포 관점에서 단 일체는 경계가 드러나지 않는다.
  • 그렇다고 해서 단 일체에는 경계가 실제로 존재하지 않거나, 경계 자체가 무의미하다는 뜻은 아니다.
  • 최종적으로는 정적으로 링크된 단일 실행 파일을 만들더라도, 그 안에 포함된 다양한 컴포넌트를 개발하고 바이너리로 만드는 과정을 독립적으로 수행할 수 있게 하는 일은 가치가 있다.
  • 이러한 아키텍처는 거의 모든 경우에 특정한 동적 다형성에 의존하여 내부 의존성을 관리한다.
  • 가장 단순한 형태의 경계 횡단은 저 수준 클라이언트에서 고수준 서비스로 향하는 함수 호출이다
    • 고수준 클라이언트가 저 수준 서비스를 호출해야 한다면 동적 다형성을 사용하여 제어 흐름과는 반대 방향으로 의존성을 역전시킬 수 있다.
    • 의존성은 저 수준 컴포넌트에서 고수준 컴포넌트로 향해야 한다.
    • 고수준 컴포넌트는 저 수준 세부사항으로부터 독립적으로 유지된다.
    • 이 책에서 말하는 고수준 컴포넌트가 사용자 인터페이스에서 더 멀고 변경이 적은 핵심 로직을 담은 컴포넌트 들이다. 로우 레벨 프로그래밍이 기계와 더 가까운 어셈블리어를 생각하고 저 수준 컴포넌트가 핵심 컴포넌트구나 생각했는데 반대였음..