단일 책임 원칙
모든 모듈이 단 하나의 일만 해야 한다 X
단 하나의 일만 해야 한다는 원칙은 따로 있다.
- 함수는 반드시 하나의, 단 하나의 일만 해야 한다는 원칙
- SRP가 아님
- 더 저수준에서 적용되는 원칙
단일 모듈은 변경의 이유가 하나, 오직 하나뿐이어야 한다.
사용자와 이해관계자
액터
하나의 모듈은 하나의, 오직 하나의 액터에 대해서만 책임져야 한다.
모듈이란?
우발적 중복
예시
테스트 코드 짰으면 발견은 했지 않을까?
동일한 기능일 지라도 사용 목적이 다른 경우에는 따로 구현하는 것이 맞는 걸까?
목적이 다르니 로직에서 달라지는 경우도 있는 건데, 그렇더라도 결국 공통된 로직은 있을텐데 아예 분리하는게 맞는 건가? 단계를 더 나누고 하위로직들만 재사용하면 되지 않을까?
비지니스 로직 설계 시 공통된다고 가정을 했을텐데,
언제든 비지니스 로직은 변경될 수 있다.
이 때에는 분리 되어야 한다.
여기서 말하는 건 액터가 다르기 때문에 처음부터 무조건 분리한다.
( 실무에서 이게 가능한가? )
if ( 이 팀이면 )
if ( 저 팀이면 )
이런 식으로 조건문이 걸리게 된다면 분리되어야 함을 뜻한다.
ex)
- 어드민 사이트에서 결제
- 파트너 사에서 결제
- 고객이 결제
→ 실무에서 적용하는 플로우 생각해보기
1. 중복 로직은 공통으로 사용한다. 다만 사용되는 곳마다 달라질 경우 발견될 수 있는 수단이 있어야 한다. (테스트 코드 등)
2. 문제가 발견 됐으면 다시 구상해서 설계 구조를 변경한다.
2. 또는 액터에 따라 동작이 달라져서 액터를 판단하는 조건문들이 들어오기 시작했다면, 목적이 달라졌다는 의미이므로 분리한다.
SRP는 서로 다른 액터가 의존하는 코드를 서로 분리하라고 말한다.
병합
개발 팀이 나뉘어 있다.
DBA가 속한 CTO 팀에서 DB의 Employee 테이블 스키마를 약간 수정함
인사 담당자가 속한 COO 팀에서는 reportHours() 메서드의 보고서 포맷을 변경하기로 했다.
⇒ 충돌나고, 결과적으로 병합이 발생함.
어떤 도구도 병합이 발생하는 모든 경우를 해결할 수는 없다.
병합은 위험이 따른다.
각 팀은 변경에 대해 인지하지 못하고, 이슈를 맞게 된다.
⇒ 서로 다른 액터를 뒷받침하는 코드는 처음부터 분리하자.
해결책
Employee의 데이터 자체는 공용으로 쓸 테니까, 이건 ‘데이터’로써 분리하여 공통으로 사용한다.
로직은 클래스별로 달라질 수 있도록 각 클래스별로 분리한다.
- 각 클래스는 자신의 메서드에 대해서만 안다.
- 각 클래스는 서로의 존재를 모른다.
⇒ 우연한 중복을 피할 수 있다.
퍼사드 패턴 (Facade 패턴)
결론
컴포넌트 수준으로 가면 공통 폐쇄 원칙이 된다.
아키텍처 수준에서는 아키텍처 경계의 생성을 책임지는 변경의 축이 된다.