[소프트웨어 아키텍처 101] 8. 컴포넌트 기반 사고

인상깊은 부분

[[콘웨이 법칙]]

조직구조나 의사소통 방식이 시스템에 묻어난다는 현상, 콘웨이 법칙은 살아있다. “조직문화부터 MSA까지” | 요즘IT

최상위 아키텍처를 분하하는 두 가지 방법

기술 분할(ex: 레이어드, Common/Local)과 도메인 분할(ex: DDD, 모듈러 아키텍처)
아키텍트는 개발자, 비즈니스 분석가, 도메인 전문가와 협력해서 시스템을 어떻게 분할할지(즉, 기술 분할할지, 도메인 분할할지) 결정하고 그에 따른 초기 컴포넌트를 설계한다.

컴포넌트 세분도

[[아키텍처 101 8. 컴포넌트 기반 사고#컴포넌트 세분도]]
적절한 크기/단위의 컴포넌트 식별은 어려운 것 같다.

아키텍처 스타일에 따른 컴포넌트 식별 방법 케미

p154 [[아키텍처 101 8. 컴포넌트 기반 사고#8.6 컴포넌트 설계]]

식별된 아키텍처 퀀텀 수에 따른 아키텍처 선정(모놀로식 or 분산)

p161 [[아키텍처 101 8. 컴포넌트 기반 사고#8.8 아키텍처 퀀텀 딜레마 모놀로식이냐, 분산 아키텍처냐]]

궁금한 것

• p143 아래 문장 이해하지 못함. 근데 그냥 넘어가도 될듯
  이 책에서 다루는 내용은 거의 다 소프트웨어 개발팀이 사용하는 것들과 독립적이므로 아키텍처는 개발 프로세스의 영향을 받지 않습니다. 이 규칙의 첫 번째 예외는 애자일 소프트웨어 개발 방법론의 다양한 분야를 개척한 엔지니어링 프랙티스를 필요로 하는데, 특히 배포 및 자동화 거버넌스 분야가 그렇습니다.
• p150 도메인 분할의 단점, '유저 정의 코드가 여기저기 널려 있다.' 비슷하게 반복되는 코드를 의미하는걸까? infra layer나 도메인별로 작성된 persistance layer를 생각하면 이해가 가는 것 같기도..?
• p151 기술 분할의 단점, '개발자가 공통 레이어, 로컬 레이어 양쪽에 도메인 개념을 복제해야 할 수도 있다.'

---

요약

8.1 컴포넌트 범위

• 컴포넌트는 아키텍처에서 서브시스템이나 레이어 형태로도 나타나며, 많은 이벤트 프로세서를 위한 배포 가능한 작업 단위 이다.
  • 연관된 코드를 묶은 래퍼(or 라이브러리), 레이어 또는 서브 시스템, 이벤트 프로세서, 분산 서비스 등
  • 마이크로서비스 같은 아키텍처에서 서비스는 배포 가능한 독립적인 단위를 형성함
• 다양한 컴포넌트 변형 => 컴포넌트의 수준이나 형태는 맥락에 따라 다름

8.2 아키텍트 역할

• 아키텍트는 아키넥처 내부의 컴포넌트를 정의, 개선, 관리, 통제하는 일을 함
• 아키텍트는 (특히 설계 패턴을 발견하여 적용할 때) 클래스 설계에 참여해서도 안 되고 시스템의 세세한 설계 결정에 관여해서도 안됨
• 최상위 아키텍처 분할 (= 기술 분할 or 도메인 분할)
  • 기술적 분할 : 레이어드 아키텍처와 같이 기술적인 능력에 따라 아키텍처를 구성하는 것
    • 시스템 기능을 기술적인 능력(ex: 프레젠테이션, 비즈니스 규칙, 서비스, 퍼시스턴스) 등으로 분할하였기 때문에 코드를 쉽게 찾을 수 있으며 이해하기 쉬움
    • 레이어드 아키텍처가 대세가 된 이면에는 흥미로운 부수 효과로 [[콘웨이 법칙]]이 있음
    • 이 아키텍처의 구성 원칙 중 하나는 기술 관심사의 분리로서, 이는 유용한 수준의 디커플링(반결합, 분리)을 만들어 변경 전파를 제한함. 이런 식으로 분할하면 의존하는 컴포넌트에 부수 효과가 전파되지 않도록 막을 수 있음. 시스템을 기술적으로 분할하여 구성하는 것에 대한 트레이드 오프는 고려해야함. [[아키텍처 101 10. 레이어드 아키텍처 패턴]] 에서 자세히 다룸
    • 커스텀 코드가 명확하게 분리된다
    • 레이어드 아키텍처 패턴에 더 가깝게 맞출 수 있다.
    • 단점
      • 전역 커플링이 더 높다. 공통 또는 로컬 컴포넌트 중 하나라도 변경되면 다른 모든 컴포넌트가 영향받을 가능성이 높다.
      • 개발자가 공통 레이어, 로컬 레이어 양쪽에 도메인 개념을 복제해야할 수도 있다. (?)
      • 일반적으로 데이터 레벨의 커플링이 높다. 분산시스템으로 아키텍처를 옮기려고 할 경우 데이터 관계를 파헤치는 작업이 어렵다.
  • 도메인 분할 : 워크플로우 또는 도메인에 따라 아키텍처를 구성하는 것
    • 에릭 에반스의 DDD에서 비롯된 것으로, DDD에서 아키텍트는 서로 독립적으로 분리된 도메인 또는 워크플로를 식별하는데, 이는 [[아키텍처 101 7. 마이크로서비스 아키텍처 스타일]] 의근본 사상이기도 함
    • 도메인 분할의 각 컴포넌트는 레이어를 포함한 서브컴포넌트를 가질 수 있지만, 최상위 분할은 도메인에 초점을 두기 때문에 프로젝트에서 가장 자주 발생하는 변경의 유형들이 더 확실히 반영됨
    • 세부 구현보다 비즈니스 기능에 더 가깝게 모델링됨
    • [[역 콘웨이 전략]]을 활용하여 도메인별 다목적팀(cross-functional team)을 구성하기 쉬움
    • 모듈러 모놀리스와 마이크로서비스 아키텍처 스타일에 더 가깝게 맞출 수 있음
    • 메시지 흐름이 문제 영역과 일치함
    • 데이터와 컴포넌트를 분산 아키텍처로 옮기기 쉬움
    • 단점
      • 유저 정의 코드가 여기저기 널려있게 됨 (?)
• 아키텍처 패턴 :서로 다른 아키텍처 패턴 간의 근본적인 차이점 중 하나가 최상위 분할의 유형(기술 or 도메인)임
• 8.3 개발자 역할
• 개발자는 아키텍트와 공동 설계한 컴포넌트를 바탕으로 클래스, 함수, 서브컴포넌트로 더 잘게 나눔. 일반적으로 클래스, 함수 설계는 공동의 책임이지만 대부분 개발자가 담당함
• 개발자는 아키텍트가 설계한 컴포넌트가 최종판이라고 생각해선 안되고, 이터레이션을 거쳐 점점 다듬어가야함. 초기 설계는 일단 초안을 보고 차후 구현을 하며 상세한 것들을 밝히고 하나씩 개선하면 됨8.4 컴포넌트 식별 흐름
• 컴포넌트 식별은 후보를 도출하고 피드백을 통해 다듬어가는 과정을 반복하는 것이 가장 좋음
• (p152 그림 8-8) 컴포넌트 식별 주기 : 초기 컴포넌트 식별 -> 요구사항을 컴포넌트에 할당 -> 역할 및 책임 분석 -> 아키텍처 특성 분석 -> 컴포넌트 재구성 -> (다시 역할 및 책임 분석)
  1. 초기 컴포넌트 식별 : 최상위 분할 유형(기술 or 도메인)에 따라 최상위 컴포넌트를 어디서부터 시작할지 결정하고 어느 기능을 어디에 둘지 도메인 기능을 매핑함. 초기 식별한 컴포넌트들만으로 제대로 된 설계가 나올 가능성은 거의 없으니 아키텍트는 컴포넌트 설계를 이터레이션하면서 조금씩 개선해야함
  2. 요구사항을 컴포넌트에 할당 : 컴포넌트에 요구사항(or 유저 스토리)을 대입하여 잘 맞는지 확인. 이 과정에서 컴포넌트를 새로 만들거나 기존 컴포넌트를 통합하고, 하는 일이 너무 많은 컴포넌트를 분해할 수 있음.
  3. 역할 및 책임 분석(+세분도 검토) : 컴포넌트에 스토리를 대입할 때 아키텍트는 요구사항을 파악하는 단계에서 밝혀진 역할과 책임을 살펴보고, 세분도(granularity)가 적합한지 확인해야함. [[아키텍처 101 8. 컴포넌트 기반 사고#8.5 컴포넌트 세분도]]와 도메인의 세분도를 짚어내는 것은 아키텍트의 가장 어려운 일 중 하나임. 그래서 더욱 이터레이션 과정이 필요함
  4. 아키텍처 특성 분석 : 컴포넌트에 요구사항을 대입할 때 아키텍트는 앞서 식별한 아키텍처 특성들이 컴포넌트 분할 및 세분도에 어떤 영향을 미치는지 살펴봐야함. 순수하게 기능적인 관점에서만 컴포넌트를 설계하면 유저 상호작용을 처리하는 단일 컴포넌트가 도출되지만, 아키텍처 특성을 분석하면 더 하위 컴포넌트로 잘게 나눌 수 있음 => 단순히 요구사항만 충족하는 서비스/컴포넌트가 아니라, 아키텍처 특성을 고려한 설계가 필요하다는 뜻 (ex: 동일한 기능이더라도 유저 동접이 몰리는 서비스는 아키텍처 특성이 다를 수 밖에 없음)
  5. 컴포넌트 재구성 : 개발자들과 함께 지속적으로 컴포넌트 설계를 반복하며 피드백을 받아야함8.5 컴포넌트 세분도
  6.  

컴포넌트에서 가장 적당한 세분도를 찾는 것은 아키텍트의 가장 어려운 작업 중 하나입니다. 컴포넌트를 너무 잘게 나누어 설계하면 컴포넌트 간 통신이 너무 많아지고, 그렇다고 너무 크게 나누면 내부적인 커플링지 긍가해서 배포, 테스트가 어려워지고 모듈성 관점에서도 부정적인 영향을 미칩니다

• 1.  

8.6 컴포넌트 설계

컴포넌트를 발견하는 몇 가지 일반적인 방법과, 안티패턴 중 하나인 엔티티 함정에 대해 안내

• 컴포넌트를 발견하는 몇 가지 방법 : 각 기법들은 다 일장일단이 있음. 폭포수 모델과 같은 소프트웨어 개발 프로세스를 사용하는 팀이라면 일반적인 액터/액션 접근법을 선호할 것이고, DDD와 마이크로서비스 같은 아키텍처를 사용하는 프로젝트는 이벤트 스토밍이 소프트웨어 개발 프로세스에 더 잘 맞음. 팀에 특별한 제약이 없고 범용적인 컴포넌트 분할을 고려하고 있다면 액터/액션 접근법이 일반적으로 괜찮은 솔루션임
  • [[액터/액션 접근법]]
  • [[이벤트 스토밍]]
  • [[워크플로 접근법]]
• [[엔티티 함정(entity trap) 안티패턴]]

8.7 컴포넌트 발굴 사례 연구 : GGG

p157 GGG 카타에 액터/액션 접근법을 적용하여 컴포넌트 발굴하는 예제

8.8 아키텍처 퀀텀 딜레마 : 모놀로식이냐, 분산 아키텍처냐

• 모놀로식 아키텍처
  • 보통 배포 단위가 하나밖에 없으므로 단일 데이터베이스에 접속하여 실행되는 모든 시스템 기능이 포함됨
• 분산 아키텍처
  • 모놀로식 아키텍처와 정반대로, 자신의 체계를 갖추고 네트워킹 프로토콜을 통해 서로 통신하는 여러 서비스로 구성됨. 배포 단위가 잘게 나뉘어 있고 서비스별로 개발팀과 우선순위를 정해 자체 릴리스 주기와 엔지니어링 프랙티스를 수립
• 식별된 아키텍처 퀀텀 수에 따른 아키텍처 선정(모놀로식 or 분산)
  • 아키텍처 스타일은 저마다 다양하 트레이드오프가 있지만, 근본적인 결정은 설계 프로세스 중에 식별된 아키텍처 퀀텀 수에 좌우됨
  • 만약 시스템이 단일 퀀텀만으로 가능하다면 모놀리스 아키텍처가 장점이 더 많음
  • 반면에 컴포넌트마다 아키텍처 특성이 달라지는 경우에는 이를 수용할 수 있는 분산 아키텍처가 필요함. 서로 다른 아키텍처 특성이 혼재되어 있는 경우 분산 아키텍처를 선택하는 것이 유리함
  • 아키텍처 퀀텀을 활용하면 초기 설계 단계에서 아키텍처의 근본적인 설계 특성(모놀리스냐 분산이냐)을 결정할 수 있으므로 아키텍처 특성의 범위와 커플링을 분석하는 방법으로서 장점이 부각됨