현재 문제

• 사용하는 기술이 자주 변경될 수 있음 ⇒ 4 layered 아키텍쳐 사용해서 기술에 대한 의존성 분리
• 테이블 숫자가 많이 늘어남
  • 도메인 별로 묶기…?

4 layered

• 특정 기술의 의존성을 줄이기 위해서 port에 interface 선언
• 구체적인 구현 방법은 infra에서 implements해서 구현
• 특정 기술에 대한 구현체는 Infrastructure 계층에 구현, 해당 기술이 필요한 usecase 에서 port 패키지에 추상화된 인터페이스만을 받아서 사용

Presentation 계층 - 사용자에게 노출되는 곳 ( Controller, converter ) Application 계층 - 시나리오 class ( Dto, Repository, Service?? ) , + 인증/인가도 가능, 인터페이스 Domain 계층 - (exception) ( model -> entity, enum ) infra 계층 - DB(RDS), RepositoryImpl 구현체, jpaRepository

현재 진행상황… 어렵다 🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯🤯

튜터님 피드백

최원빈 튜터님

• 어떻게 그룹핑할지가 중요
  • 묶는 것 자체는 좋다고 생각
  • 지금 하려는게 서비스에서 너무 많은 레포지토리를 의존하니까 그룹핑하는거지? → ㅇㅇ
• DDD
  • 중심 코어 도메인, 하위 도메인 두는 식으로 구상
  • 하위 도메인 수정은 코어 도메인에 의해 수정되는 식으로 보통 설계됨
  • 코어 도메인을 중심으로 묶는 것 → 좋다고 생각
  • 결합도 좋아지지만 비대해지고 복잡하게 엮이면 테스트 격리해서 하기 어려움
• 사용하지 않는 다른 도메인의 레포지토리들도 그룹핑?
• 유즈케이스 단위별로 묶기?
• 4 - Layer
  • 지금 우리가 사용하는건 4 레이어, 핵사고날 짬뽕 느낌?
  • 컨트롤러-서비스 사이에 퍼서드 레이어
  • 헥사곤 아키텍쳐 핵심 → 순수 도메인 로직
• 파일 늘어나는 것 두려워하는 것은 어폐
  • 파일 수 줄어든다고 좋은 아키텍쳐다? → NO
  • 파일이 늘어나도 패키지 관리할 수 있게 분리 잘 되어 있으면 문제 X