피드로 돌아가기
Dev.toBackend
원문 읽기
Specification Pattern υπό το πρίσμα του SOLID και της Clean Architecture
Specification Pattern을 SOLID 원칙과 Clean Architecture에 통합해 도메인 로직을 독립적인 조합 가능한 객체로 분리
AI 요약
Context
Repository나 Service 클래스에 복잡한 필터 로직이 직접 포함되면서 Single Responsibility Principle을 위반하고, 새로운 필터 요구사항이 발생할 때마다 기존 메서드를 수정해야 하는 Open/Closed Principle 위반이 발생한다.
Technical Solution
- ISpecification 인터페이스 정의:
bool IsSatisfiedBy(T entity)메서드를 통해 단일 조건 검증 로직을 캡슐화 - 단일 책임 클래스 작성: ActiveProductSpecification, PriceSpecification 등 각각의 규칙을 독립적인 클래스로 구현
- AndSpecification를 통한 조합: 여러 ISpecification 인스턴스를 조합해 복잡한 필터를 런타임에 구성
- Repository 메서드 단순화:
GetProducts(ISpecification<Product> specification)형태로 추상화하여 도메인 로직을 인프라 계층에서 제거 - Expression Tree 확장: ISpecification을 데이터베이스 쿼리 레벨까지 전달 가능하도록 확장
Key Takeaway
Specification Pattern은 필터링 메커니즘이 아니라 도메인 규칙을 아키텍처 경계에 맞게 정렬하는 설계 선택이며, 각 규칙이 독립적으로 테스트 가능해지고 새 규칙 추가 시 기존 코드 수정이 불필요해진다.
실천 포인트
도메인 로직이 변경되기 쉬운 비즈니스 시스템에서는 필터 조건을 Repository의 쿼리 메서드 대신 ISpecification을 구현한 독립 클래스로 분리하면, 각 조건을 단위 테스트할 때 외부 의존성(DB, Framework)을 mocking하지 않아도 되고 새로운 조건 추가 시 기존 코드 수정 없이 새 클래스만 작성하면 된다.