클린 아키텍처 요약 - 3부 설계원칙 (1)

좋은 아키텍처를 정의하는 원칙은 SOLID다.

SOLID는 1980년대 유즈넷(과거 페이스북)에서 설계 원칙을 모아 탄생시켰다. 이 원칙의 목적은 '중간수준'의 소프트웨어 구조가 아래와 같도록 만드는 것이다.

• 변경에 유연
• 이해하기 쉬움
• 많은 소프트웨어에 사용될 수 있는 컴포넌트

중간수준 뜻 : 개발자가 모듈 수준에서 작업할 때 적용할 수 있다는 뜻.

 

SOLID 요약

• SRP (Single Responsibillity Principle, 단일책임원칙)
  • 모듈 변경의 이유는 하나여야 함.
• OCP (Open Closed Principle, 개방-폐쇄 원칙)
  • 코드를 수정하기 보단 새로운 코드를 추가하는 방식으로설계해야 함.
• LSP (Liskov Subsitution Principle, 리스코프 치환 원칙)
  • 소스트웨어 구성요소는 반드시 서로 치환 가능해야 함
• ISP (Interface Segregation Principle, 인터페이스분리 원칙)
  • 설계자는 사용하지 않은 것에 의존하지 않아야 한다.
• DIP (Dependency Inversion Principle, 의존성 역전 원칙)
  • 고수준 정책을 구현하는 코드는 저수준 세부사항을 구현하는 코드에 절대로 의존해선 안된다.

 

7장. SRP : 단일책임원칙

하나의 모듈은 오직 하나의 Actor(사용자, 이해관계자)에 대해서만 책임져야 한다. 모듈은 단순히 소스 파일이다.

원칙을 위반하는 징후1. 우연한 중복

급여 어플리케이션을 구성하는 Employee 클래스 예제로 설명.

1. calculatePay()는 회계팀에서 정의하며, CFO 보고에 사용된다.
2. reportHours()는 인사팀에서 정의하고, COO 보고에 사용된다.
3. save()는 DBA가 정의하고, CTO 보고에 사용된다.

• 이때 초과 근무에 대한 요건이 추가되어 regularHours() 라는 함수가 생겼다고 생각해보자.
• 그럼 위 1,2에서 정의했던 함수들에게도 초과근무에 대한 처리(regularHours())가 필요할 것이다. 이렇게 되면 서로 다른 Actor가 의존하는 코드가 된다.
• 서로 다른 Actor가 의존하는 코드를 너무 가까이 배치했기 때문에 발생한다.

 

원칙을 위반하는 징후2. 병합

위 Employee 예제를 다시 한번 사용

1. DBA가 속한 CTO팀에서 Employee 테이블을 수정한다
2. 인사담당자가 속한 COO팀에서 reportHours() 포맷을 수정한다
3. 각각의 팀에 속한 개발자가 Employee class를 checkout받아 수정하고 이들의 변경사항은 충돌한다.

 

해결책

서로 다른 Actor를 책임지는 코드를 서로 분리한다.

 

데이터와 메서드를 분리하는 방식

• 아무런 함수가 없는 데이터 구조의 EmployeeData 클래스 생성한다,
• 각 계산 클래스는 자신의 메서드에 반드시 필요한 소스코드만 포함한다.

 

퍼사드패턴 방식1

• 위 방식의 단점은 세가지 클래스를 인스턴스화 해야한다.
• EmployeeFacade 클래스가 세가지 클래스를 생성하고 실행한다. 즉, 역할을 위임받음

 

퍼사드패턴 방식2

• Employee 클래스를 퍼사드로 사용한다.
• 가장 중요한 메서드는 기존 Employee에 그대로 유지하고 덜 중요한 메서드들의 퍼사드가 된다.