확장성 있는 아키텍처 고려사항

• 설계의도
• 도메인 끼리의 의존성을 최대한 낮추어 응집도를 높이고 필수불가결 하게 발생되는 결합은 한곳으로 집중
  • 장점
    • MSA 전환 용이
    • 명시적인 폴더 구조
    • 원활한 업부 분배 가능
    • 최소한의 기능을 가진 도구를 모아 사용한다는 유닉스 철학 채용
      • 기능 추가 용이 - 데코레이트 패턴 or 복합체 패턴
  • 단점
    • 적응 전 까지 복잡한 구조
    • 많은 폴더 깊이
    • 여전히 결합도 존재
    • 코어 기능 변경에 대해서는 높은 사이드 이펙트 가능성 존재

application: 구현체의 집합

1. commonRepository: 공용으로 쓰일수 밖에 없는 레포지토리 모음
   1. 예) 유저
2. domainName: 다른 도메인에 의존하지 않는 독립적인 기능의 집합
   1. controller: 외부 요청을 받아 결과값을 반환 하는 계층
   2. dto: 계층간 이동을 위한 데이터 타입
      1. request: 요청 데이터 타입
      2. response: 반환 데이터 타입
   3. repository: 다른 도메인에 노출될 필요가없는 레포지토리
   4. usecase: 의존성 결합 계층 & 서비스 호출 담당 → Facade
      1. 예) 파일에 “A” 라는 단어 쓰고 저장
      2. service: 비즈니스 로직 구현체
         1. 예) 파일 열기, 파일 읽기, 파일 쓰기, 파일 저장

config: 전역적으로 쓰이는 설정값

domain: 순수 자바 or 코틀린 으로 구성된 도메인

1. common: 공용으로 쓰이는 엔티티 혹은 데이터 타입의 집합
2. domainName: 다른 도메인에 의존하지 않는 독립적인 기능의 집합
   1. enums
   2. vo: 외부 계층이 아닌 같은 계층 끼리의 데이터 교환 타입 → 값 검증 수행
   3. module: 비즈니스 로직 추상화 계층

infra: 외부 서비스 or 프레임워크 에 의존하는 구현체의 집합

utils: 공용으로 쓰이는 유틸리티

• 예) 검증 유틸리티, 예외처리, 변환 유틸리티

개발 고려사항

• 기간내에 정의된 요구사항에 대해서 빠르게 개발 하는것을 우선 순위로 산정
• 지속적인 테스트를 통해 정상적으로 동작하는 프로그램을 개발하는것을 두번째 우선 순위로 산정
• 좋은점
  • 기간내에 빠르게 개발 완료
  • API 명세서 생성 → 클라이언트 페이지 개발 용이
  • 테스트 를 위한 Swagger 기능 구현
• 아쉬운점
  • 추가 기능 으로 유저 정보를 가져오는 기능 미 구현
  • 추가 기능 으로 Redis를 통한 세션 기능 미 구현
  • JWT 리프레쉬 기능 미 구현
  • Swagger 에 가이드 파라미터 미 정의

차후 고려사항