Sparta(JAVA심화3기) - TIL/Chap.01

Chap.01 : Project Day 4 - Scrum

Dev.99_tale 2025. 2. 17. 15:13

Ch.1 AI 활용 비즈니스 프로젝트

어제 한일, 오늘 할일,  내일 할일

장애물 개선

 

장소 : ZEP

 

참여자 : 서동우(튜터), 정민수, 염금성, 노현지, 이지언

 

스크럼 진행

1.  각자 개발 진행 사항 확인

2. 문제점 해결

3. 개발 진행 마무리 결정 및 테스트 진행일 결정

 

어제 작업



주말 간단하게 개발 진행 사항 확인

도메인 정의 작성

Getter / Setter 사용여부 확인

UUID 사용 전략이 다양하다 - 평일 스크럼으로 결정

관리자, 가게 주인 상세조회 권한 확인

금일 작업


각자 개발 진행사항 보고

 

도메인 정의 (책임)추가

  • 각 도메인을 역할, 협력(연관관계), 책임 기준으로 정의합니다.
  • 예를 들어, 주문 도메인에서는 상품이 주문할 상품에 대한 책임을 집니다.
  • 주문, 주문아이템, 상품 등이 서로 협력하며, 어떤 액터가 누구에게 요청하고 응답하는지 명확하게 해야 합니다.

 

계층 간 의존성 관리

  • 의존성은 한 방향으로만 흘러야 함
    • 계층 간 관계는 아래와 같이 단방향이어야 합니다.
      • Presentation ← Application ← Infrastructure
    • 순환참조(예: presentation → application → presentation)는 피해야 합니다.
  • 접근제어 Setter사용의 문제점
    • 문제점
      • Setter를 public으로 제공하면 외부에서 객체 상태를 임의로 변경할 수 있어, 객체의 일관성을 해칠 위험이 있습니다.
      • 또한, 의도치 않은 값 변경으로 인한 버그 발생 가능성이 높아집니다.
    • 해결책
      • 필요한 경우 setter의 접근 범위를 private 또는 protected로 제한하거나, 아예 제공하지 않고 생성자나 빌더 패턴을 통해 객체 상태를 설정하는 것이 좋습니다.
  • DTO와 엔티티 변환
    • 정적 팩토리 메소드와 빌더 패턴을 사용하여 DTO와 엔티티 간의 변환을 처리합니다.
    • ModelMapper 등 자동 변환 도구에 비해, 정적 팩토리 메소드와 빌더 패턴은 직접 구현하므로 성능 상 이점이 있을 수 있습니다.
 

관련문서 특강으로 보여주신다 (수요일에 참고)

 

DTO와 Entity 변환 도구 : ModelMapper

  • ModelMapper
    • DTO와 엔티티 간 변환을 자동화해주지만, 상황에 따라 성능 이슈가 발생할 수 있습니다.
  • 대안
    • 정적 팩토리 메소드와 빌더 패턴을 활용하면, 케이스별로 유연하게 변환 로직을 구성할 수 있으며, 직접 구현하기 때문에 성능 상 이점이 있을 수 있습니다.

 

계층 구조와 모듈 분리 관련 고려사항

  • 현재 계층 간 순환 문제가 있어, 의존성은 반드시 한 방향이어야 합니다.
  • 큰 프로젝트에서 모듈이 분리될 경우, 빌드 문제가 발생할 수 있으므로 DTO와 프레젠테이션 계층 DTO의 분리를 신중하게 고려해야 합니다.

 

비즈니스 로직의 위치와 관리

  • 서비스 계층에 모든 비즈니스 로직을 몰아넣으면
    • 로직 파악이 어려워지고 인지 복잡도가 상승합니다.
  • 대안
    • 도메인 모델이나 응용 계층에 분산시켜 응집도를 높이는 것이 좋습니다.
    • DDD(도메인 주도 설계)를 활용하여 각 도메인의 책임에 맞게 로직을 분리하는 방식을 권장합니다.

 

UUID 사용 전략

  • 스프링 버전이 올라가면서 여러 UUID 생성 방법이 제공됩니다.
  • 문제
    • 일부 generator는 DB에 종속적일 수 있음.
  • 결정
    • PostgreSQL 환경에 맞춰, @UUIDGenerator를 사용하는 것이 더 유리하다고 결정됨.
  • 옵션
    • @UUIDGenerator 옵션은 오토, 랜덤, 위치 등 3가지 중에서 선택할 수 있습니다.

 

 

개발 일정

  • 내일 오후(화요일)
    • 각 팀원의 개발 진행 상황을 확인한 후, 저녁에 테스트 진행 여부 결정
  • 수요일
    • 저녁에 테스트 진행 여부를 확정하고, 수요일 내에 테스트를 완료 및 상황에 따라 배포도 진행
  • 목요일
    • 배포 진행
  • 이후
    • MSA 전환 작업을 시작하며, 다음주 월요일 4시에 마무리하고 다음주 월요일(24일 18시까지) 결과물을 제출합니다.

 

 

 

코드리뷰 - 튜터님 권한 부여

설계 도면 - 도메인 개념 모델 관계도

내일 작업


각 팀원의 개발 진행 상황을 확인한 후, 저녁에 테스트 진행 여부 결정

 

스크럼 진행 및 튜터님 코드리뷰 참고