피드로 돌아가기
Dev.toBackend
원문 읽기
Noun-oriented 설계 탈피를 통한 Capability 중심 고응집 아키텍처 전환
Your Nouns Are Not Your Architecture
AI 요약
Context
도메인 명사 기반의 UserService, OrderService와 같은 Noun-oriented Architecture 채택에 따른 비대해진 Service 레이어 문제 분석. 단순 CRUD를 넘어 복잡한 비즈니스 로직이 추가됨에 따라 하나의 서비스가 모든 의존성을 갖는 God Object로 변질되는 병목 현상 발생.
Technical Solution
- 시스템이 수행해야 할 '능력(Capability)' 중심의 Agentive Naming 도입을 통한 책임 분리
- UserService와 같은 포괄적 명사 대신 PasswordResetter, AccountMerger 등 구체적 행위 기반의 컴포넌트 설계
- 거대 Capability를 더 작은 단위의 하위 Capability들로 구성하는 Explicit Composition 구조 적용
- 모든 비즈니스 로직을 3계층(Controller-Service-Repository)에 강제하지 않고, 필요 레이어만 선택적으로 사용하는 유연한 스택 구성
- 의존성 분석을 통한 Extractability 검증으로 컴포넌트 간의 논리적 경계 및 고립성 확보
- 단순 명칭 변경이 아닌 변경 이유(Reason to change)와 소유권(Ownership)이 동일한 로직의 전략적 응집
실천 포인트
- 서비스 클래스 이름이 -Service, -Manager, -Helper로 끝나는지 확인하고 구체적인 행위 중심의 이름으로 변경 검토 - 하나의 서비스 클래스 내에 서로 다른 보안 정책이나 의존성을 가진 메서드들이 혼재되어 있는지 분석 - 특정 기능을 분리했을 때 다른 서비스의 절반 이상을 함께 가져와야 하는지 Extractability 테스트 수행 - 불필요한 3계층 구조 통과를 지양하고 비즈니스 복잡도에 맞는 최소 레이어 설계 적용
태그