[Loopers - WIL] 3, 4주차 회고

🧠 이번 주에 새로 배운 것

• 도메인 모델링을 통해 현실 세계 개념과 규칙을 객체 지향적으로 표현하는 방법을 익혔습니다.
  • Entity, Value Object, Domain Service의 구분과 책임을 명확히 이해했습니다.
  • 유스케이스 기반으로 객체 간 협력을 설계하고 레이어드 아키텍처에 DIP를 적용하는 방식을 학습했습니다.
• 트랜잭션과 동시성 제어의 실무 중요성을 배웠습니다.
  • 단순 @Transactional만으로는 막을 수 없는 정합성 문제(Lost Update 등)를 실습으로 확인했습니다.
  • 비관적 락과 낙관적 락의 차이와 각각 적합한 상황을 이해했습니다.
  • ACID 원칙과 DB 격리 수준이 실제 애플리케이션 정합성에 미치는 영향을 학습했습니다.
• 동시성 테스트 작성법(CountDownLatch + ExecutorService)을 적용하여, 기능 구현 이후에도 안전성을 보장하는 방법을 경험했습니다.

💭 이런 고민이 있었어요

• 기능 설계 단계에서 도메인 개념을 어디까지 분리할 것인지에 대한 기준이 애매했습니다.
  예를 들어, 좋아요 기능을 단순 카운팅에서 독립 도메인으로 분리하는 시점의 판단 근거를 고민했습니다.
• 비관적 락과 낙관적 락을 적용할 때 성능과 안정성의 균형을 어떻게 잡아야 할지 명확하지 않았습니다.

💡 앞으로 실무에 써먹을 포인트

• 초기 설계에서 Entity, VO, Domain Service를 구분하고 협력 관계를 명확히 설계하면 이후 리팩토링 비용을 크게 줄일 수 있습니다.
• 재고 차감, 포인트 차감 등 공유 자원 변경이 필요한 로직은 반드시 동시성 제어 전략(비관적/낙관적 락 포함)을 고려해야 합니다.
• DB 격리 수준, 트랜잭션 전파 설정은 “기본값”에만 의존하지 말고 비즈니스 시나리오에 맞춰 명시적으로 지정하는 습관이 필요합니다.

🤔 아쉬웠던 점 & 다음 주 계획

• 도메인 설계와 트랜잭션/락 전략을 별개로 생각했던 습관 때문에, 구현 후에 동시성 문제를 발견하는 경우가 있었습니다.
• 다음 주에는 조회 성능 최적화(인덱스, 캐시, 조회 전략)를 학습하며, 읽기 병목 구간까지 포함한 전체 유스케이스 성능 설계를 시도해볼 계획입니다.
• "내 코드에 무게를 더한다"는 마음으로, 각 구현에 이유와 근거를 명확히 담고, 기능 동작뿐 아니라 정합성과 성능까지 고려한 코드를 작성할 예정입니다.

📝 오늘의 단어장

1. 마스터 슬레이브

마스터가 데이터를 기록·관리하고, 슬레이브가 이를 복제해 읽기 전용으로 제공하는 분산 처리 방식
참고로 최근에는 “Master/Slave”라는 용어가 차별적 뉘앙스를 지닌다는 이유로,
IT 업계에서는 “Primary/Replica”, “Leader/Follower” 같은 용어를 더 권장하고 있다고 한다.

2. Lost Update

동시에 수정된 데이터 중 하나의 변경이 다른 변경에 의해 덮어써져 사라지는 동시성 문제