단일책임원칙에 대한 고민

단일책임원칙은 '클래스는 변경이 일어나야하는 이유가 하나여야 한다'고 말한다. 단일책임원칙을 적용하면 유지보수성이 증가하고 테스트도 쉬워지고 후에 CQRS를 적용할때도 용이하다

다만 비밀로그의 퍼블릭 메서드는 최소 100개 이상이다 150~200개 까지 될 수도 있다. 그럼 클래스도 100개 이상 생긴다

그런데 모조리 단일책임원칙을 적용하는게 맞을까?
어느정도 분리하는건 좋지만 모조리 적용하면 클래스가 너무 많아질 것 같다.

클래스란.. 속성과 동작을 정의하며 객체를 생성하기 위한 틀이다. 자바 공식문서에서는 '클래스를 특정 종류의 객체를 구현하는 데 필요한 타입을 정의한다'라고 설명하고있다

특정 객체.. 하나의 성격.. 그 성격에 맞는 타입들

클래스의 관점에서봐도 단일책임 원칙이 맞아보인다 하지만 현실적으로 클래스가 너무 쪼개져있으면 관리하기 어렵지않을까? 적당히 비슷한 성격으로 모아두는게 제일 효율적이지 않나?

예를들어 카카오 외부API들을 호출하는 카카오서비스 클래스도 메서드마다 SRP를 적용하는게 맞나?
카카오 메서드 호출이라는 하나의 성격에 맞는거같은데 하나의 객체라기하기엔 여러 역할을 가지고있으니 짬뽕 같지만..

기본적인 원칙과 틀에 맞춘다고 유연성을 잃는 것이 아닐까 생각이 든다

아무튼 내 비밀로그는 심하게 하나의 클래스가 여러 역할을 가지고있기에 역할분리가 필요하긴하다 다만 그것을 어느정도로 강하게 적용할지 고민이다. 하다가 너무 불편해지면 그 지점이 틀에서 벗어난 필요가있는 유연성을 가질 필요가 있을 지점일까..?

더 나아가서 클린 아키텍처를 구축할 때 SRP를 꼭 만족해야 성과가 나오는 이유라도 있을까? 이건 아키텍처를 공부해야 할 것 같다

도메인, 즉 소프트웨어가 다루는 문제의 영역, 개발자 중심의 비즈니스 논리 기준, 비즈니스의 주제별 책임 단위..

요점은 도메인의 분리다.
도메인을 분리 시키는 것이 SRP의 중요한 측면이 아닐까라는 생각이 든다. 아마 상위 아키텍처들도 도메인 단위로 무언가를 하지않을까?

SRP는 규칙이 아니라 지침이다 결국 하나의 클래스는 하나의 변경으로만 바뀌어야한다면 비슷한 변경점을 가진 메서드들 즉 도메인들은 묶어도 된다고 생각한다.

도메인은 기존에도 분리했지만 범위가 너무 넓었다 단순히 유저, 게시판, 롤링페이퍼로 도메인을 분리하지말고 역할과 성격, 책임으로 도메인을 분리하고 SRP측면에서 관찰해야한다고 생각한다.