본문 바로가기

Design/Architecture

[Clean Architecture] 컴포넌트

SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면,

컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해 준다.


큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다.

 

컴포넌트란?

컴포넌트는 배포단위이다.

  • 자바에서는 jar파일
  • 루비에서는 gem파일
  • 닷넷에서는 DLL파일
  • 인터프리터형 언어에서는 소스 파일의 결합체

잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한, 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다.

 

 

컴포넌트의 역사

컴포넌트의 역사를 간단히 훑어보도록 하자.

 

  1. 초기 라이브러리 함수는 소스코드에 직접 포함시켰음.
    => 메모리크기의 제한으로 인해, 컴파일을 나눠서해야했으므로 컴파일 과정이 매우 느렸음
  2. 라이브러리를 소스코드로 부터 분리하고, 미리 별도 컴파일하여 특정 메모리 위치에 로드.
    => 애플리케이션의 크기와 라이브러리 사용이 늘어나면서 할당된 메모리공간을 벗어나게 되면서 세그먼트화가 심해짐.
  3. 로더를 사용하여 메모리를 재배치할 수 있는 방식을 채택. 라이브러리를 외부정의하여 프로그램이 외부참조할 수 있도록 함.(링킹로더)
    => 로드와 링크를 한꺼번에 진행하다보니 시스템이 커질 수록 링킹 로더의 속도가 매우 느려짐.(링크가 매우 느린 주 원인)
  4. 링크와 로드를 분리. 링커는 링크가 완료된 재배치 코드를 생성. 로더가 메모리에 코드를 빠르게 로드.
    =>미리 링크된 파일은 언제든지 빠르게 로드될 수 있음.
  5. 최근에는 CPU의 속도가 매우 빨라졌고, 메모리의 용량도 커지면서 다시 로드와 링크를 함께 할 수 있게됨.
    =>이렇게 되면서 컴포넌트 플러그인 아키텍처가 탄생. (.jar 파일과 같은 공유 라이브러리를 순식간에 링크하여 실행)

 

결론

런타임에 플러그인 형태로 결함할 수 있는 동적 링크파일이 이 책에서 말하는 컴포넌트이다.

 

 

참고)

컴포넌트 내용은 앞의 SOLID의 내용을 충분히 숙지하고 접근할 필요가 있으니 반드시 복습할 것! (링크)