[책] 클린아키텍처: 컴포넌트 원칙

문돌이 개발자·2025년 1월 21일

컴포넌트 응집도 3원칙

REP: Reuse/Release Equivalence Principle

  • 재사용 단위는 릴리스 단위와 같다.
    단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어 같은 릴리스할 수 있어야 한다.

CCP: Common Clousre Principle

  • 컴포넌트 수준에서의 SRP
  • 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라, 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라

CRP: Common Reuse Principle

  • 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 마라
  • 같이 재사용되는 경향이 있는 클래스는 같은 컴포넌트에 포함해야 한다.
  • 컴포넌트에서 단 하나의 클래스에 의존하는 경우와 컴포넌트의 모든 클래스에 의존하는 경우의 의존성은 다르지 않다. 똑같이 해당 컴포넌트에 같은 강도로 의존한다.

    세가지 원칙이 서로 상충되고 있다. 결국 상황에 맞춰 컴포넌트 포함수준을 정해야 한다.

컴포넌트 관계 3원칙

ADP: Acyclic Dependency Principle

  • 컴포넌트 의존성 그래프에 순환이 있어서는 안된다.
    열심히 개발한 무언가가 동작하지 않을 때 -> 의존하던 무언가가 수정되어서

주 단위 빌드

  • 개발자가 각자 개인적으로 코드를 작성하고 한주를 마무리하면서 코드를 통합하고 빌드하는 방법
  • 프로젝트가 커질수록 통합에 드는 비용이 커지고, 회피하게된다. 개발자 간 빠른 피드백이 어려워지게 됨

순환 의존성 제거

  • 각 개발자 혹은 개발팀이 컴포넌트를 담당하고 릴리스한다. 릴리스된 컴포넌트에 대해서만 의존성을 갖고 개발하는 방법

순환 의존성의 문제점

  • 컴포넌트 의존성이 연쇄적으로 일어나 각 컴포넌트가 하나의 거대한 컴포넌트로 묶인 것처럼 취급해야 함

순환 끊기

  1. DIP를 적용, 의존하는 컴포넌트에 interface를 위치시킨다. 의존을 받는 컴포넌트는 해당 interface를 상속받는다.
  2. 두 컴포넌트가 모두 의존하는 새로운 컴포넌트를 생성한다.

Top-Down 설계

  • 컴포넌트는 미리 설계하고 개발할 수 있는 영역이 아니다.
  • 프로젝트를 진행하면서 컴포넌트 구조는 계속 변경되고 수정되어 진화한다.

SDP: Stable Dependency Principle

  • 안정성의 방향으로 의존하라
  • 변경하기 어려운 컴포넌트를 변동성이 큰 컴포넌트에 의존하게 만들지 마라

안정성

  • '쉽게 움직이지 않는'
  • 변경하기 어려운 컴포넌트는 수많은 컴포넌트가 의존하고 있는 컴포넌트
  • 독립적인 컴포넌트는 외부에 의존성을 갖지 않고 자신이 책임지는 컴포넌트가 많은 컴포넌트를 의미
  • 의존적인 컴포넌트는 외부에 의존성을 많이 갖고 있어 변동 가능성이 높은 컴포넌트를 의미

안정성 지표

  • Fan-in: 안으로 들어오는 의존성
  • Fan-out: 밖으로 나가는 의존성
  • 불안정성: I = Fan-out/(Fan-in + Fan-out), I가 1에 가까울수록 불안정
  • 많은 의존성을 책임지는 컴포넌트일수록 더 안정적이어야 한다.

추상 컴포넌트

  • 오로지 인터페이스만 포함하는 컴포넌트는 의존성 제어를 위해 꽤 흔하게 사용된다.

SAP: Stable Abstractions Principle

  • 컴포넌트는 안정된 정도만큼만 추상화되어야 한다.

고수준 정책을 어디에 위치시켜야 하는가?

  • 안정된 컴포넌트에 고수준 정책을 위치시키면 해당 소스코드는 변경하기 어려워지고 유연성이 떨어지게 된다.
  • abstract class를 통해서 유연성을 보장한다.

안정된 추상화 원칙

  • 안정성이 컴포넌트 확장을 방해해서는 안된다.

    만들고 싶은 서비스를 구체화할 때 변하지 않을 본질적인 기능들을 나열하고 인터페이스화하는게 설계의 시작이라고 배운적이 있다. 구현은 얼마든지 변경가능하고 또 다른 인터페이스와 조합해서 확장할 수 있도록 추상화를 중심으로 설계해나가는 게 중요한 것 같다.

추상화 정도 측정

  • Nc: 컴포넌트의 클래스 개수
  • Na: 컴포넌트의 추상 클래스와 인터페이스 개수
  • A: 추상화 정도 Na/Nc

사실 개발하다보면 느낄 수 있는 부분이 원칙과 글로 설명되어있어 좋았다. 기회가 된다면 측정도 해보고 싶다.

profile
까먹고 다시 보려고 남기는 기록

0개의 댓글