Clean Architecture 정리 - 3부 7장 단일 책임 원칙

단일 책임 원칙은 "하나의 모듈은 오직 하나의 변경 이유만을 가져야 한다"는 원칙이다.

여기서 말하는 '책임'은 메서드 수가 아니라, 이해관계자(Actor)의 관점에서 모듈이 변경되어야 할 이유를 뜻한다.

 

=> 내가 더 쉽게 풀어서 설명한다면, 하나의 액터의 관점으로 모듈을 설계해야한다는 뜻인 것 같다.

 

[ 오해: 하나의 모듈에 하나의 메서드만 있어야 한다? ]

메서드 수가 중요한 게 아니라, 모듈이 오직 하나의 액터만을 위해 존재하는가?가 핵심이다.

 

하지만, 리팩토링을 위해 큰 메서드를 나눌 때, 하나의 메세드에 하나의 기능을 수행하게 나누는 원칙은 존재한다.

 

여러 액터(이해관계자)를 위한 설계 X

public class DocumentManager {
    public void writeToFile() {
        // 시스템 관리자의 요구사항: 문서 파일로 저장
    }

    public void formatForPrint() {
        // 디자이너의 요구사항: 출력용 포맷팅
        String content = getPlainText();
        // 출력 포맷 적용...
    }

    public void getWordCount() {
        // 기획자의 요구사항: 문서 분량 통계
        String content = getPlainText();
        int count = content.split("\\s+").length;
        // 통계 처리...
    }

    private String getPlainText() {
        // 공통 유틸: 마크다운 제거 등
        return "example plain text";
    }
}

이 클래스는 다음 세 명의 액터의 요구를 모두 담고 있다:

• 시스템 관리자: 파일 저장
• 디자이너: 포맷팅 출력
• 기획자: 단어 수 분석

 

결과적으로 발생하는 문제는 다음과 같다:

• 한 액터의 변경이 다른 액터에 영향을 준다
• 공통 유틸 메서드로 인해 불필요한 결합 발생
• 병합 충돌 가능성 증가 (여러 액터가 같은 파일을 건드림)

만약 디자이너 요청으로 getPlainText() 내부 로직을 수정했는데, 기획자 쪽 통계 결과가 이상해졌다면?

... 한동안, 문제를 찾지 못할 것이다.

 

결론: 각 액터의 요구는 별도의 모듈로 분리하자!

 

※ 본 글은 『Clean Architecture』(로버트 C. 마틴 저) 3부의 7장을 기반으로 학습 목적으로 요약한 글입니다.

※ 이 글은 책의 내용을 요약한 것으로, 원문 없이 읽을 경우 오해의 여지가 있을 수 있습니다. 정확한 이해를 위해 원서의 정독을 권장합니다.