| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 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
- 임베딩
- 레디스스트림
- 배치처리
- DLT
- aof
- 레디스
- blockingqueue
- rdb
- springboot
- Kafka
- god object
- 메세지브로커
- 코사인
- jedis
- redisstreams
- redissearch
- 마케팅 #퍼플카우 #새스고딘 #혁신 #독서 #이북
- OOP
- SaaS
- retry
- 비동기처리
- 메시지브로커
- 백엔드
- 객체지향적사고
- 장애복구
- 테스트코드
- 데이터유실방지
- redis
- 시맨틱캐싱
- 자연어캐싱
Archives
- Today
- Total
목록테스트코드 (1)
pandaterry's 개발로그
서비스 클래스가 점점 무거워질 때, 우리는 한 번쯤 이런 생각을 합니다.“나는 오케스트레이션만 하니까 괜찮지 않나?”“도메인 객체는 그냥 데이터 구조잖아.”“유효성 검사는 서비스에서 다 하면 되는 거 아냐?” 실제로 몇몇 개발자들도 이런 구조를 문제 삼지 않고 넘기곤 합니다. SRP를 지켰다거나, 도메인을 분리했다는 형식적 명분으로 충분하다고 느낄 수도 있기 때문입니다. 하지만 진짜 중요한 건 그 구조가 정말 도메인의 책임과 역할을 반영하고 있는가입니다. 이번 글에서는 흔히 "이 정도면 괜찮다"라고 여겨지는 코드들이 실제로는 어떤 문제를 유발할 수 있는지를 검토하고, 그에 대한 개선 방향을 구체적인 코드와 함께 살펴보았습니다. 총 4가지 예시를 준비해봤습니다 :) 예시 1. OrderService – ..
개발/OOP
2025. 6. 23. 23:34