[클린 아키텍처] 3부. 설계 원칙

출처 : yes24

🎯  설계 원칙 

1. SRP(Single Responsibility Principle) : 단일 책임 원칙 
2. OCP(Open-Closed Principle) : 개방-폐쇄 원칙
3. LSP(Liskov Substitution Principle) : 리스코프 치환 원칙
4. ISP(Interface Segregation Principle) : 인터페이스 분리 원칙
5. DIP(Dependency Inversion Principle) : 의존성 역전 원칙

 

 

---

❗ SRP : 단일 책임 원칙

하나의 모듈은 오직 하나의 액터에 대해서만 책임져야 한다.
모듈이란? 
 - 단순한 정의로 소스 파일

 

징후1) 우발적 중복

Employee라는 클래스 안에 calculatePay, reportHours, save 메서드가 3명의 액터를 책임진다.

즉, 단일 클래스에 세 액터가 결합되어 있다.

• calculatePay() : 회계팀에서 기능을 정의하며, CFO 보고를 위해 사용한다.
• reportHours() : 인사팀에서 기능을 정의하고 사용하며, COO 보고를 위해 사용한다.
• save() : 데이터베이스 관리자가 정의

 

문제 상황!!

-> regularHours() : 초과 근무를 제외한 업무 시간을 계산하는 알고리즘

• calculatePay() 와 reportHours() 각각의 메소드에서 regularHours()를 사용
• calculatePay()에서 업무시간 계산의 변경을 위해 regularHours()메소드를 변경하면, calculatePay도 영향이 간다.
• 개발자가 regularHours()를 변경할 때, calculatePay()도 regularHours()를 호출하고 있는 것을 알고 있을까? -> 모른다.
• 이 모든 것은 서로 다른 액터가 의존하는 코드를 너무 가까이 배치했기 때문. -> 코드 분리 필요

 

징후2) 병합

소스 파일에 다양하고 많은 메서드를 포함하면 병합이 자주 발생한다.

변경사항이 생겨 CTO개발자가 Employee ERD를 변경시키고, 이와 동시에 COO팀에서 보고서 format을 변경했다고 생각해보자.

CTO팀과 COO팀은 원본 A를 pull 받아 변경하고, 적용하려 할텐데 변경사항들을 서로 충돌한다. 

이러한 병합에는 항상 위험이 따른다.  

 

해결책 

- 메서드를 각기 다른 클래스로 이동시키는 방식.
- 데이터와 메서드를 분리시키는 방식

 

위의 예시의 해결책으로, 간단한 데이터 구조인 EmployeeData 클래스를 만들어 세 개의 클래스가 공유하도록 하자.

• 세 클래스는 서로의 존재를 몰라야 한다. 따라서 "우연한 중복"을 피할 수 있다. 

 

반면, 이 해결책은 개발자가 세 가지 클래스를 인스턴스화하고 추적해야 한다는 게 단점이다.

이런 난관에서 빠져나오기 위해, 퍼사드 패턴 이 존재.

• Facade클래스에 코드는 거의 없다.
• 세 클래스의 객체를 생성하고, 요청된 메서드를 가지는 객체로 위임하는 일을 책임진다. 

++ Facade클래스는 내부 서브시스템의 내부를 알지 않아도 Facade클래스의 메소드를 호출하면 해당 API를 제공할 수 있도록 만들어주는 역할을 한다. (라이브러리의 역할이라고 보면 이해하기 쉽다.)

 

퍼사드 패턴 출처 : https://jusungpark.tistory.com/23

 

어떤 개발자는 가장 중요한 업무 규칙을 데이터와 가깝게 배치하는 방식을 선호하는데, 

이 경우에는 가장 중요한 메서드는 기존의 Employee클래스에 그대로 유지하되, 덜 중요한 나머지 메서드들에 대한 퍼사드로 사용할 수도 있다.

 

 

 

❗ OCP : 개방-폐쇄 원칙

소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
즉, 개체의 행위는 확장할 수 있어야 하지만, 변경해서는 안된다. 

예시)  재무제표를 웹 페이지로 보여주는 시스템이 있는데, "프린트 출력 기능"이 추가되었다고 생각해보자.

얼마나 많은 코드를 수정해야할까?

• 소프트웨어 아키텍처가 훌륭하다면, 변경되는 코드의 양이 가능한 한 최소화될 것이다. (이상적인 변경량은 0)

 

어떻게 하면 최소화 시킬 수 있을까? 

• 보고서용 데이터 계산 책임, 웹/프린트 형태로 표현하는 책임, 두 개의 책임으로 분리시키자.
• 두 책임 중 하나에서 변경이 발생하더라도 다른 하나는 변경되지 않도록 소스코드 의존성을 확실히 조직화해야한다. 
• 위의 목적을 달성하기 위해서는 처리 과정을 클래스 단위로 분할하고, 클래스는 컴포넌트 단위로 분리한다. 
  • 컴포넌트 : Controller, Interactor, Presenter, Database, View

 

• 주목할 점 1 : 모든 의존성이 소스 코드 의존성을 나타낸다.
  • 화살표가 A 클래스에서 B 클래스로 향한다면, A 클래스에서는 B클래스를 호출하지만, B클래스에서는 A클래스를 전혀 호출하지 않음.
• 주목할 점 2 : 이중선은 화살표와 오직 한 방향으로만 교차한다.
  • 모든 컴포넌트 관계는 단방향으로 이루어진다는 뜻. (즉, 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.)
  • A컴포넌트에서 발생된 변경으로부터 B 컴포넌트를 보호하려면 반드시 A 컴포넌트가 B컴포넌트에 의존해야 한다.
  • 예제) Presenter에서 발생한 변경으로부터 Controller를 보호하고자 한다. 
• 왜 Interactor는 OCP를 가장 잘 준수할 수 있는 곳에 위치하나? 
  • Interactor가 업무 규칙을 포함하기 때문.
  • 가장 높은 수준의 정책을 포함하기 때문.
  • 이렇게, 높은 수준(중심적인 문제-ex.Interactor)일수록 보호를 받고, 낮은 수준(View)일수록 보호를 받지 못한다. 

Interface의 목적

1. 방향성 제어

• FanancialDataGateway 인터페이스는 의존성을 역전시키기 위해 사용

2. 정보은닉

• FanancialReportRequester 인터페이스는 Controller가 Interactor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재. 

결론

• OCP :  시스템의 아키텍처를 떠받치는 원동력 중 하나
• 목표 : 시스템 확장성 및 변경으로 인해 시스템에 영향을 받지 않도록 하기 
  
  • 컴포넌트 단위로 분리
  • 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들기.

 

❗ LSP : 리스코프 치환 원칙

리스코프 치환 원칙 
S타입의 객체 o1, T타입의 객체 o2가 있다고 해보자. o2자리에 o1을 치환하더라도 문제가 없다면, S는 T의 하위 타입이다. 

상속을 사용하도록 가이드하기

• License(Interface) 의 두 가지 하위타입
  • Personal License
  • Business License

-> Personal License와 Business License는 모두 License 타입을 치환할 수 있다.

 

정사각형/직사각형 문제

출처 : https://uchanlee.dev/clean-architecture/book/ch9/

User는 Rectangle을 바라보고 있고, Sqare는 width, height를 독립적으로 바꿀 수 없기 때문에 Rectangle의 하위타입으로는 적합하지 않다. 결국 이 설계는 User에게 혼동을 일으킨다.

한가지 해결방법으로 User가 Square인지 확인하는 코드를 추가할 수 있지만, User의 행위가 사용하는 타입에 의존하게 되기 때문에 결국 타입을 치환할 수 없게 된다. 

 

LSP와 아키텍처

초창기 LSP는 상속을 사용하도록 가이드하는 정도로만 간주되었지만, 시간이 지나면서 인터페이스/구현체에도 적용되는 광범위한 소프트웨어 설계 원칙으로 변해왔다.

LSP를 이해하는 최선의 방법은 원칙을 어겼을 때 시스템 아키텍처에서 무슨 일이 일어나는지 관찰하는 것이다.

 

LSP 위배 사례

카카오T에서 택시 업체들을 배차 및 수락 서비스를 만들때, "pickupAddress", "pickupTime", "destination"을 사용하여 동일한 방식으로 로직을 처리했다고 가정해보자. 

그런데, 서울택시에서 이 서비스 사양을 제대로 파악하지 못하고 "destination"필드를 -> "dest"로 축약해서 사용했다. 

 

어떻게 될까?

모듈에 if문을 추가하고, 서울택시가 서울남양택시 업체를 인수했을 경우는 따로 처리해야하는 로직이 필요하다.

아주 매끄럽지 않고 복잡한 매커니즘을 추가해야할 것이다.

결론

LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야한다.

치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 매커니즘을 추가해야 할 수도 있기 때문에..

 

❗ ISP : 인터페이스 분리 원칙

정적 타입 언어로 작성되었다고 할 때, OPS라는 인터페이스에 op1, op2,op3가 있고, User1는 op1만, User2는 op2만, User3는 op3만 사용한다고 하자.
op2가 변경되었을 때, 관련없는 User1클래스도 다시 컴파일하고 새로 배포해야 한다.
-> 그렇기 때문에 인터페이스를 분리하자.

ISP와 아키텍처

시스템 S -> 프레임워크 F -> DB D 
( -> : 의존성 방향 )

• F에서는 불필요한 기능, 즉 S와는 관계없는 기능이 D에 포함될 때, 그 기능 떄문에 D의 구조가 변경되면 F,S 모두 재배포 해야할지 모른다.
• 더 심각한 문제는 D 내부의 기능 중 F와 S에서 불필요한 기능에 문제가 발생해도 F와 S에 영향을 준다는 사실.

결론

• 불필요한 짐을 실은 무언가에 의존하면 예상치 못한 문제에 빠진다.

 

❗ DIP : 의존성 역전 원칙

소스코드 의존성이 추상에 의존하며 구체에는 의존하지 않아야 시스템은 유연성이 높아진다. 
즉, "자신보다 변하기 쉬운 것에 의존하지 마라!"

안정된 추상화

추상 인터페이스에 변경이 생기면 이를 구체화한 구현체들도 따라서 수정해야 한다.

즉, 자신보다 변하기 쉬운 것에 의존하지 마라!

 

DIP 지키기 : 안정된 소프트웨어 아키텍처

• 변동성이 큰 구체 클래스를 참조하지 마라.
  • 대신, 추상 인터페이스를 참조하자.
• 변동성이 큰 구체 클래스로부터 파생하지 마라.
  • 상속은 신중하게 하자.
• 구체 함수를 오버라이드 하지 마라.
  • 구체함수는 소스코드 의존성을 필요로 한다.
  • 의존성을 제거하려면 차라리 추상 함수로 선언하고, 구현체들에서 각자 용도에 맞게 구현하자.
• 구체적이며 변동성이 크다면 절대로 그 이름을 언급하지 마라.