‘클린 아키텍처’ 기술 서적에 대해 학습했던 내용을 정리하기 위한 목적의 TIL 포스팅입니다.🙆‍♂️

4부 컴포넌트 원칙

• SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면, 컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다.
• 큰 빌딩과 마찬가지로 대규모 소프트웨어 시스템은 작은 컴포넌트들로 만들어진다.

12장 컴포넌트

컴포넌트가 무엇인지 컴포넌트의 역사에 대해 설명하는 내용이다. 크게 중요한 내용은 많지 않아서 컴포넌트가 무엇인지 그리고 어떻게 소프트웨어가 발전하게 되었는지를 가볍게 보면 좋다.

• 컴포넌트는 시스템의 구성요소로 배포할 수 있는 가장 작은 단위다.
  • 자바 - jar
  • 루비 - gem 파일
  • 닷넷 - DLL
• 컴파일형 언어에서 컴포넌트는 바이너리 파일의 결합체다. 인터프리형 언어의 경우 소스 파일의 결합체이다.
• 모든 언어에서 컴포넌트는 배포할 수 있는 단위 입자다.
• 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성 가능하다.
• 또는 여러 컴포넌트를 서로 묶어서 war 파일과 같은 단일 아카이브로 만들 수도 있다.
• 또는 컴포넌트 각각을 jar 나 dll 같이 동적으로 로드할 수있는 플러그링닝나 exe 파일로 만들어서 독립적으로 배포할 수도 있따.
• 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 간으한, 따라서 독립적으로 개발 가느한 능력을 갖춰야 한다.

컴포넌트의 간략한 역사

• 프로그래밍 초창기에는 프로그램을 로드할 메모리의 위치를 정하는 일이 프로그래머가 가장 먼저 결정해야 하는 사항 중 하나였다.
  • 이 시절엔 프로그램 위치가 한 번 결정되면, 재배치가 불가능했다.
• 이러한 구시대에는 프로그래머가 라이브러리 함수의 소스 코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일하여 해당 라이브러리에 접근했다.
  • 라이브러리는 바이너리가 아닌 소스 코드 형태로 유지되었다.
• 이 시대엔 장치는 느리고 메모리는 너무 비싸서 자원이 한정적이었기에, 이러한 접근법은 문제가 있었다.
  • 이 시대엔 메모리가 너무 작아서 소스 코드 전체를 메모리에 상주시킬 수 없었고, 컴파일러는 소스 코드 전체를 여러번에 걸쳐서 읽어야했다.
  • 이 과정은 엄청오래 걸렸다.
• 따라서 함수 라이브러리의 소스 코드를 애플리케이션 코드로부터 분리하고, 함수 라이브러리를 개별적으로 컴파일해, 컴파일된 바이너리를 메모리의 특정 위치에 로드했다. (102p-그림12.1 초기의 메모리 배치 이미지 참고)
• 하지만, 이 방식도 초기에 할당된 메모리보다 애플리케이션이 더 커지게 되자, 애플리케이션을 두 개의 세그먼트로 분리하여 함수 라이브러리 공간을 사이에 두고 오가며 동작하게 배치해야 했다.
• 하지만 이것은 분명 지속 가능한 방법이 아니었다.

재배치성

• 해결책은 재배치가 가능한 바이너리였다.
• 바로 로더를 이용해서 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하자는 것이었다.
• 프로그래머는 함수 라이브러리를 로드할 위치와 애플리케이션을 로드할 위치를 로더에게 지시할 수 있게 되었다.

• 로더는 바이너리르 입력받은 후, 단순히 하나씩 차례로 메모리로 로드하면서 재배치하는 작업을 처리하였고, 프로그래머는 필요한 함수만을 로드할 수 있게 되었다

• 컴파일러는 재배치 가능한 바이너리 안의 함수 이름을 메타데이터 형태로 생성하도록 수정되었다.
  • 프로그램이 라이브러리 함수를 호출한다면 외부 참조(external reference)로 생성했다.
  • 프로그램이 라이브러리 함수를 정의한다면 외부 정의(external definition)로 생성했다.
• 이렇게 함으로써 외부 정의를 로드할 위치가 정해지기만 하면 로더가 외부 참조를 외부 정의에 링크시킬 수 있게 된다. 이를 링킹 로더라고 한다.

링커

• 1970년대 초가 되자 프로그램이 커지게 되고, 링킹 로더는 프로그램을 로드하는데 매우 긴 시간이 걸렸다.
• 이를 해결하고자 로드와 링크가 분리되었다.
• 프로그래머가 느린 부분, 즉 링크 과정을 맡았는데, 링커라는 별도의 애플리케이션으로 이 작업을 처리하도록 만들었다.
  • 링커는 링크가 완료된 재배치 코드를 만들어 주었고, 그 덕분에 로더의 로딩 과정이 아주 빨라졌다. 그리고 한 번 만들어준 실행 파일은 언제라도 빠르게 로드할 수 있게 되었다.
• 하지만 또 1980년대가 되어 프로그래머는 C나 또 다른 고수준 언어를 사용하기 시작했고 프로그램도 더 커지게 되었다.
  • 그러다보니 컴파일-링크 시간이 병목 구간이되어 또 다시 전체 모듈을 컴파일하는데 엄청난 시간이 들게 되었다… (끊이지 않는 반복..)
• 이후 기술이 발전하여 디스크 속도가 증가하고 액티브X와 공유 라이브러리, jar 파일이 등장했으며, 다수의 .jar 또는 공유 라이브러리를 순식간에 서로 링크한 후, 링크가 끝난 프로그램을 실행할 수 있게 되었다.
• 이렇게 컴포넌트 플러그인 아키텍처가 탄생했다.

결론

• 런타임에 플러그인 형태로 결합할 수 있는 동적 링크 파일이 이 책에서 말하는 소프트웨어 컴포넌트에 해당한다.

13장 컴포넌트 응집도

• 어떤 클래스를 어느 컴포넌트에 포함시켜야 할 지는 중요한 결정이다.
• 이 장에선 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다.
  • REP(Reuse/Release Equivalence Principle) - 재사용/릴리스 등가 원칙
  • CCP(Common Closure Principle) - 공통 폐쇄 원칙
  • CRP(Common Reuse Principle) - 공통 재사용 원칙

REP: 재사용/릴리스 등가 원칙

재사용 단위는 릴리스 단위와 같다.

• 소프트웨어 컴포넌트가 릴리스 절차를 통해 추적 관리되지 않거나 릴리스 번호가 부여되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 할 수도 없고, 하지도 않을 것이다.
• 릴리스 번호가 없다면 재사용 컴포넌트들이 서로 호환되는지 알 수가 없다.
• 개발자들은 릴리스 변경사항을 통해 기존 버전을 쓸지 아니면 새로운 릴리스 변경사항을 적용할지를 결정 가능하다.
• 이 원칙을 소프트웨어 설계와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈로 구성되어야 함을 뜻한다.
  • 단순히 뒤죽박죽 임의로 선택된 클래스와 모듈로 구성되선 안된다.
• 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다.
• 하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스 할 수 있어야 한다.
• 이 원칙의 약점은 다음에 다룰 두 원칙이 지닌 강점을 통해 충분히 보완할 수 있다.
  • 실제로 CCP와 CRP 는 REP를 엄격하게, 하지만 제약을 가하는 측면에서 정의한다.

CCP: 공통 폐쇄 원칙

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

• 이 원칙은 단일 책임 원칙(SRP)을 컴포넌트 관점에서 다시 쓴 것이다.
  • 공통 폐쇄 원칙 CCP 에서도 마찬가지로 단일 컴포넌트는 변경의 이유가 여러 개 있어선 안된다고 말한다.
• 유지보수성은 재상용성보다 훨씬 중요하다.
  • 애플리케이션 코드가 반드시 변경되어야 한다면, 변경 지점들이 여러 컴포넌트에 분산되어 있는 것보단 한 컴포넌트에 존재하는 것이 낫다.
  • 만약 변경 지점을 단일 컴포넌트로 제한할 수 있다면, 해당 컴포넌트만 재배포하면 되고, 변경된 컴포넌트에 의존하지 않는 다른 컴포넌트는 다시 검증하거나 배포할 필요가 없다.
• CCP는 위와 같은 이유로 변경될 가능성이 존재하는 클래스는 모두 한 곳으로 묶을 것을 권한다.
  • 물리적 또는 개념적으로 강하게 결합되어 항상 함께 변경되는 클래스들은 하나의 컴포넌트에 속해야 한다.
  • 이를 통해 소프트웨어를 릴리스, 재검증, 배포하는 일과 관련된 작업량을 최소화할 수 있다.
• 이 원칙은 개방 폐쇄 원칙(OCP)과도 밀접하게 관련되어 있다.
  • 실제로 CCP의 폐쇄는 OCP의 폐쇄와 그 뜻이 같다.
  • 100%의 폐쇄는 불가능한데 변경 가능성이 있거나 과거에 발생했던 대다수의 공통적인 변경사항에 대해서 클래스가 닫혀있도록 설계한다.
• CCP에선 동일한 유형의 변경에 대해 닫혀있는 클래스들을 하나의 컴포넌트로 묶음으로써 OCP에서 얻은 교훈을 확대 적용한다.
  • 따라서 변경이 필요한 요구사항이 발생할 경우, 그 변경이 영향을 주는 컴포넌트들이 최소한으로 한정될 가능성이 확실히 높아진다.

SRP 와의 유사성

• CCP는 컴포넌트 수준의 SRP다.
• SRP에선 서로 다른 이유로 변경되는 메서드를 서로 다른 클래스로 분리하라고 말한다.
• CCP에선 서로 다른 이유로 변경되는 클래스를 서로 다른 컴포넌트로 분리하라고 말한다.
  • 두 원칙은 모두 아래와 같은 교훈으로 요약 가능하다.

동일한 시점에 동일한 이유로 변경되는 것들을 한데 묶어라. 서로 다른 시점에 다른 이유로 변경되는 것들은 서로 분리하라.

CRP: 공통 재사용 원칙

컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.

• 공통 재사용 원칙 CRP도 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움되는 원칙이다.
• CRP에선 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다고 말한다.
  • 개별 클래스가 단독으로 재사용되는 경우는 거의 없으며 대체로 재사용 가능한 클래스는 재사용 모듈의 일부로써 해당 모듈의 다른 클래스와 상호작용하는 경우가 많다.
  • CRP 에선 이런 클래스들이 동일한 컴포넌트에 포함되어야 한다고 말한다.
• 간단한 예시로 container와 iterator 클래스는 서로 강하게 결합되어 있기 때문에 함께 재사용된다. 따라서 동일한 컴포넌트에 위치해야한다.
• 또한, CPR는 동일한 컴포넌트로 묶어서는 안되는 클래스가 무엇인지도 말해준다.
  • 어떤 컴포넌트가 다른 컴포넌트를 사용하면, 두 컴포넌트 사이에 의존성이 생긴다.
  • 사용하는 클래스에서 사용되는 클래스에서 단 하나의 클래스만 사용한다고 해도 의존성은 약해지지 않는다.
  • 이런 의존성으로 인해 사용되는 컴포넌트가 변경될 때 마다 사용하는 컴포넌트도 변경해야할 가능성이 높다.
  • 따라서 의존하는 컴포넌트가 있다면 해당 컴포넌트의 모든 클래스에 대해 의존함을 확실히 인지해야 한다.
• 따라서 CRP는 어떤 클래스를 한데 묶어도 되는지보단, 어떤 클래스를 한데 묶어선 안되는지에 대해 훨씬 더 많은 것을 이야기한다.
  • CRP는 강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안 된다고 말한다.

ISP와의 관계

• CRP는 인터페이스 분리 원칙(ISP)의 포괄적인 버전이다.
• ISP는 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언한다.
• CRP는 사용하지 않은 클래스를 가진 컴포넌트에 의존하지 말라고 조언한다.
• 위 두 조언은 다음 한 문장으로 요약할 수 있다.

필요하지 않는 것에 의존하지 말라.

컴포넌트 응집도에 대한 균형 다이어그램

• 응집도에 관한 세 원칙은 서로 상충된다.
• REP와 CCP는 포함(inclusive) 원칙이며, 컴포넌트를 더욱 크게 만든다.
• CRP는 배제(exclusive)원칙이며, 컴포넌트를 더욱 작게 만든다.
• 따라서 이 원칙들이 균형을 이루는 방법을 찾아야 한다.

• 위 균형 다이어그램에서 다이어그램의 각 변은 반대쪽 꼭지점에 있는 원칙을 포기했을 때 감수해야 할 비용을 나타낸다.
  • REP와 CRP에만 중점을 두면, 사소한 변경에 너무 많은 컴포넌트에 영향을 미친다.
  • CCP와 REP에만 과도하게 집중하면 불필요한 릴리스가 너무 빈번해진다.
  • CRP와 CCP에만 집중하게 되면 재사용성이 떨어지게 된다.
• 뛰어난 아키텍트라면 이 균형 삼각형에서 현재 개발팀이 현재 관심을 기울이는 부분을 충족시키는 위치를 찾아야 하며, 또한 시간이 흐르면서 개발팀이 주의를 기울이는 부분 역시 변한다는 사실도 이해하고 있어야 한다.
  • 예를 들어, 프로젝트 초기에는 CCP가 REP보다 훨씬 더 중요한데, 개발 가능성이 재사용성보다 더욱 중요하기 때문이다.
  • 일반적으로 프로젝트는 삼각형의 오른쪽에서 시작하는 편인데, 프로젝트가 성숙하고 그 프로젝트로부터 파생된 또 다른 플조ㅔㄱ트가 시작되면, 점차 왼쪽으로 이동해 간다.
  • 즉, 프로젝트 컴포넌트 구조는 시간과 성숙도에 따라 변한다는 뜻이다.

결론

• 어느 클래스들을 묶어서 컴포넌트로 만들지를 결정할 때, 재사용성과 개발 가능성이라는 상충하는 힘을 반드시 고려해야 한다.
• 이들 사이에서 애플리케이션의 요구에 맞게 균형을 잡는 일은 중요하다. 심지어 이 균형점은 항상 유동적이다.
  • 즉, 두 힘을 현재 상황에 맞게 잘 분배했더라도, 내년엔 맞지 않을 수도 있다.
  • 결과적으로 시간이 흐름에 따라 프로젝트의 초점이 개발가능성에서 재사용성으로 바뀌고, 그에 따라 컴포넌트를 구상하는 방식도 조금씩 흐트러지고 또 진화한다.

14장 컴포넌트 결합

• 지금부터 다루게 될 세 가지 원칙은 컴포넌트 사이의 관계를 설명한다.
• 이 장에서도 마찬가지로 개발 가능성과 논리적 설계 사이의 균형을 다룬다.

1) ADP: 의존성 비순환 원칙 (Acyclic Dependencies Principle)

컴포넌트의 의존성 그래프에 순환(Cycle)이 있어서는 안 된다.

• 동일한 소스코드를 여럿이 건들게 되면, 충돌이 자주 발생하게 되고 망가진 부분을 고치느라 애를 먹을 것이다.
• 이때 해결책으론 두 가지 방법이 있다.
  • 1)주단위 빌드(Weekly Build)
  • 2)의존성 비순환 원칙(Acyclic Dependencies Principle, ADP)

1) 주단위 빌드(Weekly Build)

• 중간 규모 프로젝트에서 흔히 사용된다.
• 월-목엔 각자 개발 후 금요일에 통합한다.
  • 장점: 빠른 피드백 및 서로 신경 안쓰고 편하게 개발 가능
  • 단점: 프로젝트 통합시 오래걸림
• 위의 단점으로 인해 시간이 지날수록 통합에드는 시간이 계속 늘어나고 위기를 초래한다.

2) 순환 의존성 제거하기

• 의존성 구조에 순환이 절대 생겨선 안된다. 그렇게 되면 숙취증후군이…

• 위 이미지는 전형적인 컴포넌트 다이어그램이다. 컴포넌트 의존성 구조는 방향 그래프 임에 주의하자.
• 어느 컴포넌트에서 시작하더라도, 의존성 관계를 따라가면서 최초의 컴포넌트로 되돌아갈 수 없게 해야 한다. (비순환 방향 그래프)
  • Presenters를 담당하는 팀에서 이 컴포넌트의 새로운 릴리스를 만들면 무슨일이 벌어질지 생각해보자.
  • 이 릴리스에 영향받는 팀은 쉽게 찾을 수 있다.
  • 의존성 화살표를 거꾸로 따라가면 된다.
  • 즉, View 와 Main 컴포넌트 둘 다 영향 받는다.
  • 이 두 컴포넌트를 작업중인 개발자라면, Presenters의 새로운 릴리스와 자신의 작업물을 언제 통합할지를 반드시 결정해야 한다.
• 또한 Main은 영향 받는 컴포넌트가 전혀 없어서 쉽게 변경 가능하다.
• 시스템 전체를 릴리스해야 하면 상향식으로 진행된다.
  • Entities(컴파일, 테스트, 릴리스) → Database, Interators, → …
• 컴포넌트 구성요소 간 의존성을 파악하고 있으면 시스템을 빌드하는 방법과 순서를 알 수 있다

🙌나의 예시

• 현재 고객사 인사정보시스템으로부터 코드, 조직, 구성원 데이터를 동기화 시켜주는 람다 애플리케이션을 개발 중에 있다.
• 멀티 모듈로 구성되어 있으며, 현재 의존성 그래프는 아래와 같다. (실제 app-samsung, app-lg 는 단순히 예시이며, 고객사 모듈을 뜻한다.)

• 의존성 그래프가 단방향으로 구성되어 있으며, 비순환 형태이다. (어느 모듈에서 시작하더라도 최초 컴포넌트로 돌아갈 수 없는)
• 또한 위와 같이 설계한 이유는 고객사 모듈(ex. app-samgsung, app-lg) 간의 클래스들을 서로 격리시키기 위함이다.
• 추가적으로 전체 프로세스는 람다 함수의 페이로드 이벤트에 기반하여 매칭되는 고객사 SyncManager 를 팩토리 메서드를 통해 생성하여 실제 synchronize 메서드를 호출하여 동기화가 이뤄지는 방식이다.

순환이 컴포넌트 의존성 그래프에 미치는 영향

• 컴포넌트 간의 의존성으로 인해 순환 컴포넌트와 관련된 개발자들은 모두 서로에게 얽매일 것이다.
  • Database 컴포넌트 릴리스 -> Entities 와 반드시 호환 -> Authorize 와 호환되도록 신경써야 한다.
  • 그렇기에 릴리스하기 훨씬 어려워진다. 그러다보면 숙취증후군이…
• 테스트할때 또한 의존된 컴포넌트 체인을 따라 모두 빌드하고 통합해야 하는데 문제가 발생하게 되고 받아들이기도 힘들어진다.
• 이처럼 순환이 생기면 컴포넌트를 분리하기 상당히 어려워지고, 단위 테스트 및 릴리스도 굉장히 어려워지고 에러도 쉽게 발생한다. 게다가 모듈의 개수가 많아짐에 따라 빌드 관련 이슈는 기하급수적으로 증가한다.
• 추가적으로 컴포넌트에 대한 빌드 순서를 파악하기도 상당히 힘들어진다. 올바른 순서라는 것 자체가 없을 수 있다.

순환 끊기

• 1)의존성 역전(DIP)을 적용한다. (고수준의 Permissions 인터페이스로 저수준이 고수준을 참조하도록 변경)

• 2)Entities와 Authorizer가 모두 의존하는 새로운 컴포넌트를 만든다. 그리고 모두 의존하는 클래스들을 새로운 컴포넌트로 이동시킨다.
  • 이러한 과정을 통해 요구사항이 변겨오디면 컴포넌트 구조도 변경되게 된다. 그러기에 주기적으로 순환이 발생하는지 관찰 후 끊어줘야 한다.

하향식 설계

• 컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니기 때문에, 하향식으로 설계될 수 없다.
• 컴포넌트 의존성 다이어그램은 애플리케이션의 기능을 의미하지는 않는다.
• 오히려 애플리케이션의 빌드 가능성(buuildability)과 유지보수성(maintainability)을 보여주는 지도(map)와 같다.
• 따라서, 아무런 클래스도 설계하지 않은 상태에서 컴포넌트 의존성 구조를 설계하려고 하면 실패할 것이다.

2) SDP: 안정된 의존성 원칙 (Stable Dependencies Principle)

안정성의 방향으로 (더 안정된 쪽에) 의존하라

• 설계는 결코 정적일 수 없으며 변경은 불가피하다.
• 그러다보니 일부는 변동성을 지니도록 설계된다.
• 그래서 변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어선 절대 안된다. 한 번 의존하게 되면 변동성이 큰 컴포넌트도 결국 변경이 어려워진다.
• 안정된 의존성 원칙을 준수하면 변경하기 어려운 모듈(백엔드 도메인 모듈, 프론트 위젯 모듈)이 변경하기 쉽게 만들어진 모듈(백엔드 웹 모듈, 프론트 클라이언트 모듈)에 의존하지 않도록 만들수도 있다.

안정성

• 변경을 만들기 위해 필요한 작업량과 관련된다.
  • 변경하는데 많은 작업이 필요 == 많은 곳에서 의존된다 == 안정적이다.
• 소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법은 수많은 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.

• X는 세 컴포넌트를 책임지고 있다. 그러나, X가 변경되도록 마들 수 있는 외적인 영향은 없기 때문에 독립적이다.

• Y는 상당히 불안정한 컴포넌트이다. Y에 의존하는 컴포넌트는 없기 떄문에, 책임성이 없으며, 의존적이라고 볼 수 있다.

안정성 지표

• 불안정성 : I = Fan-out / (Fan-in + Fan-out) , I =1이면, 최고로 불안정한 컴포넌트, I = 0이면, 최고로 안정한 컴포넌트다.
  • Fan-in: 안으로 들어오는 의존성. 이 지표는 컴포넌트 내부의 클래스에 의존하는 컴포넌트 외부의 클래스 개수를 나타낸다.
  • Fan-out: 바깥으로 나가는 의존성. 이 지표는 컴포넌트 외부의 클래스에 의존하는 컴포넌트 내부의 클래스 개수를 나타낸다.
• 의존성 방향으로 갈수록 I지표 값이 감소해야 한다.

🙌나의 예시

• 위에서 언급된 동기화 람다 함수 멀티 모듈의 예시로 보면 위와 같다.
• 의존성 방향으로 갈수록 I지표 값이 감소하는 것을 볼 수 있다.
  • 즉, 의존성 방향으로 갈 수록 많은 곳에서 의존되는 것을 확인 가능하다.

모든 컴포넌트가 안정적이어야 하는 것은 아니다.

• 모든 컴포넌트가 안정적이라면, 변경은 불가능하다.
• 포인트는 의존성 방향 안쪽으로 I지표 값이 감소하지 않도록 구조를 개선해야 한다.
  • DIP 를 도입하여 의존성을 역전시켜서 이를 유지할 수 있다. (p130. 그림 14.11 참고)

추상 컴포넌트

• 오로지 인터페이스만을 포함하는 컴포넌트를 생성하는 방식인 추상 컴포넌트는 상당히 안정적이며, 따라서 덜 안정적인 컴포넌트가 의존할 수 있는 이상적인 대상이다.

3) SAP: 안정된 추상화 원칙 (Stable Abstractions Principle)

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

• 시스템에는 자주 변경해서는 절대로 안되는 소프트웨어도 있다. 고수준 아키텍처나 정책 결정과 관련된 소프트웨어가 그 예다.
• 따라서 시스템에서 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I = 0)에 위치해야 한다.
• 하지만 고수준 정책을 안정된 컴포넌트에 위치시키면, 그 정책을 포함하는 소스 코드는 수정하기가 어려워진다. 이로 인해 시스템 전체 아키텍처가 유연성을 잃는다.
• 그렇다면 어떻게 컴포넌트가 최고로 안정된 상태이면서도(I = 0) 동시에 변경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까?
• 해답은 개방 폐쇄 원칙(OCP)에서 찾을 수 있다. 추상 클래스를 활용해서 말이다.

안정된 추상화 원칙

• 안정성과 추상화 정도 사이의 관계를 정의한다.
  • 안정된 컴포넌트는 추상 컴포넌트 이며, 이를 통해 안정성이 컴포넌트를 확장하는 일을 방해해선 안된다고 말한다.
  • 불안정한 컴포넌트는 반드시 구체 컴포넌트여야 하며, 컴포넌트 내부의 구체적인 코드를 쉽게 변경할 수 있기 때문이다.
• SAP와 SDP를 결합하면 컴포넌트에 대한 DIP나 마찬가지가 된다.
  • 실제로 SDP에서는 의존성이 반드시 안정성의 방향으로 향해야 한다고 말하고
  • SDP에서는 안정성이 결국 추상화를 의미한다고 말하기 때문이다.
  • 따라서 의존성은 추상화의 방향으로 향하게 된다.
• 핵심은 안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다.

추상화 정도 측정하기

• 추상화 정도를 지표로 표현한 것이다.
  • NC: 컴포넌트의 클래스 개수
  • Na: 컴포넌트의 추상 클래스와 인터페이스의 개수
  • A: 추상화 정도. A = Na / Nc(A가 0이면 추상 클래스가 한개도 없고, 1이면 오로지 추상 클래스만 있음)

주계열

• 아래 이미지는 안정성(I)과 추상화 정도(A) 사이의 관계 그래프다.
  • 최고로 안정적이며 추상화된 컴포넌트는 (0, 1)에 위치한다.
  • 최고로 불안정하며 구체화된 컴포넌트는 (1, 0)에 위치한다.

• 모든 컴포넌트가 이 두 지점에 위치하는 것은 아니다.
• 아래 그림의 궤적은 컴포넌트가 절대로 위치해서는 안 되는 영역, 배제할 구역(Zone of Exclusion)이다.

고통의 구역

• (0, 0) 주변 구역에 위치한 컴포넌트는 매우 안정적이며 구체적이다. 뻣뻣한 상태이다. 추상적이지 않아서 확장할 수 없고, 안정적이므로 변경하기 상당히 어렵다.
• 하지만 변동성이 없는 컴포넌트는 (0, 0) 구역에 위치하더라고 해롭지 않다. 변동될 가능성이 없기 때문이다.

쓸모없는 구역

• (1, 1) 주변의 컴포넌트는 최고로 추상적이지만, 누구도 그 컴포넌트에 의존하지 않는다. 이러한 컴포넌트는 쓸모가 없다. 따라서 이 구역은 쓸모없는 구역(Zone of Uselessness)이라 부른다.

배제 구역 벗어나기

• 변동성이 큰 컴포넌트 대부분은 두 배제 구역으로부터 가능한 한 멀리 떨어뜨려야 한다.
• 최대한 멀리 떨어진 점의 궤적은 (1, 0)과 (0, 1)을 잇는 선분이다. 저자는 주계열(Main Sequence)이라 부른다.
• 주계열 위 또는 가깝게 위치해야 하며, 이렇게 위치하면 ‘너무 추상적’이지도 않고, 추상화 정도에 비해 ‘너무 불안정’하지도 않다.

주계열과의 거리

• 주계열과의 거리를 지표화한 것으로, 주계열에 대체로 일치하도록 설계되었는지를 분석할 수 있다.

🙌나의 예시

• 위에서 언급한 동기화 람다 함수를 기반으로 추상화 지표로 A/I 그래프를 그려보면 아래 이미지와 같다.

• app-samsung 컴포넌트는 변동성이 큰 모듈이다보니 두 배제 구역으로부터 멀리 떨어뜨려놓아야 하지만 그렇지 못하다.
  • 추상 클래스 및 인터페이스를 활용하여 추상화 정도를 더 높일 필요가 있다.
• app-core 컴포넌트는 고통의 구역에 속해있지만, 변동성이 거의 없는 컴포넌트이므로 크게 해롭지 않다.
• app-main 컴포넌트는 주계열선에 가깝게 위치해있다.

결론

• 이 장에서 설명하는 의존성 관리 지표 는 설계의 의존성과 추상화 정도가 내가 ‘훌륭한’ 패턴이라고 생각하는 수준에 얼마나 부합하는지를 측정한다.
• 하지만 이러한 지표는 신이 아니고 아무리 해도 불완전하다는 것을 참고하자.

Reference

• https://wedonttalknemore.tistory.com/19
• https://wedonttalknemore.tistory.com/20
• https://velog.io/@ssuh0o0/Clean-Architecture-14%EC%9E%A5-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EA%B2%B0%ED%95%A9