• 아키텍트는 보통 모듈을 물리적으로 구현한 컴포넌트로 생각
• 개발자는 자신 개발 플랫폼에 따라 여러 가지 방법으로 모듈을 물리적으로 패키징
• 이렇게 모듈을 물리적ㅇ로 패키징한 것을 컴포넌트라고 하며, 대부분의 언어는 패키징을 지원한다.

8.1 컴포넌트 범위

• 컴포넌트는 여러 파일이나 코드 조각(아티팩트)을 하나로 묶어주는 역할을 한다. 필요하다면 컴포넌트 안에 또 다른 컴포넌트를 넣어서 계층처럼 만들 수도 있다. 이 기능은 프로그래밍 언어에서 지원해준다.
• 가장 단순한 컴포넌트는 클래스보다 한 단계 높은 수준의 모듈로 코드를 래핑한 것. 이 단순한 래퍼를 보통 라이브러리라고 한다.
• 반드시 컴포넌트를 사용해야 하는 것은 아니지만, 컴포넌트는 언어가 제공하는 저수준이 아닌, 더 높은 수준에서 모듈성을 가지는 것이 더 유용할 때가 많다.
• 컴포넌트가 될 정도로 충분한 코드로 구성하거나, 적은 양의 코드만 담도록 단순한게 설계하는 것이 좋다.

8.2 아키텍트 역할

• 컴포넌트는 클래스나 함수로 구성되며, 이들은 설계하는 업무는 기술 리더나 개발자가 담당한다.
• 아키텍트는 클래스 설계에 참여해서도 안 되고 시스템의 세세한 설계 결정에 관여해서도 안 된다.

🤔 왜 안된다고 하는걸까?

세세한 업무는 기술 리더나 개발자가 담당하는 역할이기 때문이다. 아키텍트가 직접 세부 설계에 관여하게 되면, 아키텍트 본연의 역할인 전체적인 시스템 구조와 아키텍처 결정에 집중하지 못하고, 오히려 개발팀의 자율성과 책임감을 저해할 수 있다. 각자의 역할을 분리함으로써 아키텍트는 큰 그림과 원칙을 수립하고, 개발자는 구체적인 구현과 최적화에 집중하게 되어 효율적인 협업이 이루어진다.

아키텍처 분할

• 소프트에어 아키텍처 제 1법칙에 따르면 소프트웨어는 만사가 다 트레이드오프다.
• 컴포넌트는 일반적인 적재 매커네즘을 의미하므로 아키텍트는 재량껏 어떤 유형의 분할도 할 수 있다.
• 아키텍처의 구성 원칙 중 하나는 기술 관심사의 분리다.
  • 유용한 디커플링을 만든다.
  • 변경할 일이 생겨도 해당 레이어만 영향을 받도록
  • 이러면 부수 효과가 전파되지 않도록 막을 수 있다.

8.3 개발자의 역할

• 개발자는 아키텍트와 공동 설계한 컴포넌트를 바탕으로 클래스, 함수, 서브 컴포넌트를 더 잘게 나눈다.
• 개발자는 아키텍트가 설계한 컴포넌트가 최종판이라고 생각해선 안 된다.
• 모든 소프트웨어는 이터레이션을 거쳐 점점 다듬어진다.

8.4 컴포넌트 식별 흐름

초기 컴포넌트 식별 -> 요구사항을 컴포넌트에 할당 -> 역할 및 책임 분석 -> 아키텍처 특성 분석 -> 컴포넌트 재구성 -> 역할 및 책임 분석 ...

• 아키텍처는 이런 주기를 반복하면서 점점 구체화된다.

초기 컴포넌트 식별

• 아키텍터는 소프트웨어 프로젝트의 소스 코드가 생기기 전에 적용할 최상위 분할의 유형에 따라 최상위 컴포넌트를 어디서부터 시작할지 경정해야 한다.
• 그 밖에도 원하는 컴포넌트를 자유롭게 구성하면서 어느 기능을 어디에 둘지 도메인 기능을 매핑한다.
• 초기 식별한 컴포넌트들만으로 제대로 된 설계가 나올 가능성은 거의 없으니 아키텍트는 컴포넌트 설계를 이터레이션하면서 조금씩 개선해야 한다.

오구사항을 컴포넌트에 할당

• 요구사항을 대입해서 잘 맞는지 확인한다.
• 이 과정에서 컴포넌트를 새로 만들거나 기존 컴포넌트를 통합하고, 하는 일이 너무 많은 컴포넌트는 분해할 수 있다.

역할 및 책임 분석

• 애플리케이션이 지원해야 할 역할과 기능 둘 다 고려해야 컴포넌트와 도메인의 세분도를 서로 맞출 수 있다.

아키텍처 특성 분석

• 컴포넌트에 요구사항을 대입할 때 아키텍트는 앞서 식별한 아키텍처 특성들이 컴포넌트 분할 및 세분도에 어떤 영향을 미치는지 살펴봐야 한다.
• 순수하게 기능적인 관점에서만 컴포넌트를 설계하면 유저 상호작용을 처리하는 단일 컴포넌트가 도출되지만, 아키텍처 특성들을 분석하면 더 하위 컴포넌트로 잘게 나눌 수 있다.

컴포넌트 재구성

• 소프트웨어 설계에서 피드백을 항상 중요하다.
• 아키텍트는 개발자들과 함께 지속적으로 컴포넌트 설계를 반복해야 한다.
• 소프트웨어 설계를 하다보면 온갖 종류의 난관에 봉착한다.
• 접근 방식이 정말 중요하다.
  • 첫째, 차후 재설계를 하게 만들지 모를 모든 발견과 특이 사례를 전부 다 고려하기란 사실상 불가능하다.
  • 둘째, 아키텍처와 개발자가 애플리케이션 구축에 점점 더 깊이 빠질수록 서로의 기능과 역할을 어떻게 조정하면 좋을지 서로 다른 시각으로 바라보게 된다.

8.5 컴포넌트 세분도

• 컴포넌트에서 가장 적당한 세분도를 찾는 것은 가장 어려운 작업 중 하나이다.

8.6 컴포넌트 설계

• 컴포넌트 설계에 있어 왕도는 없다.
• 팀과 조직에서 사용하는 소프트웨어 개발 프로세스와 맞물려 다양한 기술과 트레이드오프가 있겠지만, 아키텍트는 아키텍처를 설계하면서 요구사항을 접수하고 애플리케이션을 구성할 구성 요소를 그려봐야 한다.