일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 29 | 30 |
31 |
Tags
- golang
- javascript
- 디자인패턴
- elasticsearch
- Intellij
- replication lag
- model context protocol
- goland
- 구조체
- sqs fifo queue
- context7
- 서비스메쉬
- redirect-gateway
- authorizationpolicy
- 2024 톨스토이문학상 수상
- RDS
- Infra
- go
- AWS
- ssh 에이전트
- 오블완
- Kubernetes
- typescript
- 티스토리챌린지
- GIT
- cosine similarity metric
- esbuild
- AI
- 캡슐화
- GoF
Archives
- Today
- Total
목록Clean Architecture (1)
Fall in IT.
MSA에서 메서드 분리에서 유스케이스 분리를 고민하는 시점
MSA 아키텍처로 여러 서비스를 운영하면서, 저는 도메인 단위로 유스케이스를 묶는 구조를 사용해 왔습니다.예를 들어, User 서비스에서는인증 관련 로직은 AuthUsecase회원 정보 관련 로직은 UserUsecase이렇게 기능별로 Usecase를 구분해 구성했습니다.AuthUsecase에는 이메일 인증, 휴대폰 인증, 본인 인증 등을, UserUsecase에는 회원가입, 로그인, 유저 정보 조회, 비밀번호 재설정 등 다양한 메서드를 구현해 관리했습니다.처음에는 이 구조가 충분히 단순하고 효과적이었습니다. 하지만 서비스가 점차 확장되고 비즈니스 요구사항이 복잡해지면서 한계가 드러났습니다.문제의 시작: 사용자 유형에 따른 분기 증가시간이 지나면서 User 서비스는 B2B와 B2C 사용자를 동시에 지원하게..
시스템구축
2025. 6. 21. 11:43