사용자 정의 유틸리티와 헬퍼로 매번 다시 바퀴를 발명하는 것을 그만두세요. 이 스킬은 유지보수 가능하고 확장 가능한 코드를 작성하는 데 도움이 되는 클린 아키텍처와 도메인 주도 설계 원칙을 가르칩니다.
스킬 ZIP 다운로드
Claude에서 업로드
설정 → 기능 → 스킬 → 스킬 업로드로 이동
토글을 켜고 사용 시작
테스트해 보기
"software-architecture" 사용 중입니다. 아키텍처 문제가 있는지 이 UserService 클래스를 검토하세요: [ 데이터베이스 쿼리, API 호출, UI 렌더링이 모두 혼합된 UserService 클래스 ]
예상 결과:
아키텍처 문제 발견: 1) 관심사 혼합 - 데이터베이스 쿼리는 Repository 레이어에 있어야 함, 2) UI 렌더링은 별도의 뷰 컴포넌트에 있어야 함, 3) API 호출은 전용 서비스에 있어야 함. 권장 리팩토링: UserRepository (데이터), UserService (비즈니스 로직), UserView (프레젠테이션) 으로 분할.
"software-architecture" 사용 중입니다. 결제 처리를 구현해야 합니다. 직접 구축해야 하나요 아니면 라이브러리를 사용해야 하나요?
예상 결과:
권장사항: 커스텀 결제 처리를 구축하는 대신 Stripe 또는 Paddle 을 사용하세요. 이러한 서비스는 PCI 준수, 반복 청구, 웹훅, 직접 구축하는 데 몇 달이 걸릴 수 있는 엣지 케이스를 처리합니다. 기존 솔루션이 요구사항을 충족할 수 없는 매우 독특한 요구사항이 있는 경우에만 커스텀 구현을 고려하세요.
"software-architecture" 사용 중입니다. 이커머스 앱의 주문 처리 모듈 설계
예상 결과:
권장 아키텍처 (DDD): 1) Order 엔터티 (도메인): Order, OrderItem, OrderStatus. 2) 리포지토리: OrderRepository, InventoryRepository. 3) 서비스: OrderService (placeOrder, cancelOrder), PaymentService (processPayment), InventoryService (reserveItems). 4) 피해야 할 안티패턴: 비즈니스 로직을 수행하는 OrderController, 컨트롤러 내의 데이터베이스 쿼리, 일반적인 OrderUtils 클래스.
보안 감사
안전All static analysis findings are false positives. Detected 'backtick execution' patterns are markdown code emphasis formatting for library names and file examples. 'Weak cryptographic algorithm' detections are references to 'Clean Architecture' design pattern, not cryptography. 'System reconnaissance' patterns match legitimate software development guidance. This skill contains no executable code and provides educational architecture guidance only.
품질 점수
만들 수 있는 것
그린필드 프로젝트 아키텍처
새로운 프로젝트를 시작하고 첫날부터 견고한 아키텍처 기반을 구축해야 함
레거시 코드 리팩토링
클린 아키텍처 원칙을 적용하여 기존 코드베이스의 코드 품질 개선
코드 리뷰 표준
팀 코드 리뷰 및 풀 리퀘스트를 위한 일관된 아키텍처 가이드라인 수립
이 프롬프트를 사용해 보세요
아키텍처 문제가 있는지 이 코드 구성요소를 검토하세요. 확인 항목: 일반적인 네이밍 (utils/helpers), UI 와 혼합된 비즈니스 로직, 200 줄을 초과하는 파일 길이, 50 줄을 초과하는 함수. 클린 아키텍처 원칙에 따라 개선 사항 제안.
[feature] 모듈을 구축해야 합니다. DDD 원칙에 따라 아키텍처를 설계하세요. 엔터티, 서비스, 리포지토리에 대한 도메인별 이름을 제안하세요. 명확한 경계와 관심사 분리를 정의하세요.
[feature] 기능을 구현해야 합니다. 이 문제를 해결하는 기존 라이브러리 또는 서비스를 검색하세요. 다음을 기준으로 옵션을 평가하세요: 유지보수 상태, 커뮤니티 채택, 문서화 품질, 요구사항 적합성.
이 코드베이스를 아키텍처 안티패턴에 대해 분석하세요: NIH 증후군 (라이브러리 대신 커스텀 구현), 일반적인 파일 이름, 부적절한 관심사 분리, 깊은 중첩. 예시와 함께 구체적인 리팩토링 권장사항 제공.
모범 사례
- 유지보수 부담을 줄이기 위해 커스텀 코드 작성 전 기존 라이브러리 및 서비스 검색
- 일반적인 utils 또는 helpers 대신 OrderCalculator 및 UserAuthenticator 와 같은 도메인별 이름 사용
- 비즈니스 로직을 프레임워크와 독립적으로 유지하고 UI 컴포넌트와 분리
- 중첩을 줄이고 코드 가독성을 개선하기 위해 early return 패턴 적용
피하기
- 도메인별 모듈 대신 관련 없는 함수가 포함된 utils.js 또는 helpers.ts 파일 생성
- 비즈니스 로직을 UI 컴포넌트와 혼합하거나 컨트롤러에 직접 데이터베이스 쿼리 배치
- 검증된 라이브러리가 존재할 때 커스텀 인증, 상태 관리 또는 폼 유효성 검사 구축
- 명확한 도메인 목적 없이 일반적 (common, shared, misc) 으로 파일 또는 모듈 네이밍