| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | 3 | 4 | 5 | 6 | 7 | 8 |
| 9 | 10 | 11 | 12 | 13 | 14 | 15 |
| 16 | 17 | 18 | 19 | 20 | 21 | 22 |
| 23 | 24 | 25 | 26 | 27 | 28 |
- @sendable
- 네이티브
- Android
- 스켈레톤 통합
- SwiftUI
- launchscreen
- panorama view
- 뷰 정체성
- React Native
- 파노라마 뷰
- completion handler
- 360도 뷰어
- ios
- 360도 이미지 뷰어
- 뷰 생명주기
- requirenativecomponent
- react-native-fast-image
- launch screen
- 라이브러리 없이
- 구조적 정체성
- ssot
- data driven construct
- 360도 이미지
- react
- 앱 성능 개선
- 리액트 네이티브
- React-Native
- 명시적 정체성
- native
- 리액트
- Today
- Total
목록2025/02/17 (3)
Neoself의 기술 블로그
BookMatchKit 리펙토링 과정-3/3 (Factory Method 패턴)
1. 3차 리펙토링2차 리펙토링 이후, 구조에 대해 아래와 같은 문제점을 파악하게 되었습니다. 1. 서비스 레이어의 분산으로 인한 응집도 저하BookSearchService는 BookMatchAPI 모듈 내부에 위치한 반면, ImageProcessService와 TextExtractionService는 BookOCRKit에 위치했으며, BookValidationService는 BookRecommendationKit 내부에 위치했습니다.때문에 같은 비즈니스 로직을 담당하는 서비스 레이어 컴포넌트끼리의 응집도가 저하되는 문제가 있었습니다. 2. 의존성 관리의 복잡성2개의 최상위 모듈이 3개의 서비스 레이어 컴포넌트들 중 일부를 직접 import하여 사용하고 있기에 Service 레이어와 Integration..
BookMatchKit 리펙토링 과정-2/3 (Template Method 패턴)
1. 2차 리펙토링이후 아래와 같은 이유들로 인해 2차 리펙토링의 필요성을 느끼게 되었습니다.- DeepSeek api처럼 로직 목표를 공유하는 다른 외부 API를 추가하거나 대체하고자 할때, 많은 개발 리소스가 소요됨.- BookMatchModule 내부 기능상 다른 역할을 하는 메서드 2개가 공존하고 있기에, 유지보수 용이성이 저하됨.- BookMatchModule 내부 세부로직들에 대한 책임이 명확히 분리되어있지 않음. 따라서 크게 4가지 변경점을 가져가고자 했습니다.1. API 계층 개선2. BookMatchModule 책임 분리3. 계층적 디렉토리 구조 도입4. 서비스 계층 도입 2. API 계층 개선 API 클라이언트 분리기존에는 DefaultAPIClient라는 단일 클래스에서 모든 API..
BookMatchKit 리펙토링 과정-1/3 (Strategy 패턴, Adapter 패턴, Facade 패턴)
이번 포스트에서는 도서 추천 및 매칭 시스템인 BookMatchKit의 아키텍처 설계 과정에 대해 살펴보겠습니다.1. 1차 리펙토링1차 리펙토링에는 단일 책임원칙 준수를 최우선 순위로 고려해 다음과 같은 주요 모듈들로 구성하게 되었습니다.BookMatchKit/├── Sources/│ ├── BookMatchAPI/ # 외부 API 통신 계층│ ├── BookMatchCore/ # 핵심 도메인 계층│ ├── BookMatchKit/ # 비즈니스 로직 계층│ └── BookMatchStrategy/ # 알고리즘 구현 계층1.1 BookMatchCoreBookMatchCore는 프로젝트의 핵심 도메인 로직을 담고 있는 모듈로써 설계했습니다.BookItem: 도..