결론

주식(도메인) 중심으로 비즈니스 규칙을 잘 담기 위해 계층형 구조를 기본으로 가져가되, 인프라 의존을 끊기 위해 DIP(Port & Adapter / Hexagonal)방식을 결합

→ 외부 API(KIS, OpenDART 등)가 늘거나 교체되어도 비즈니스 로직이 흔들리지 않도록 설계

1) 아키텍처 선택 기준

• “남들이 많이 쓰는 아키텍처”라고 무조건 따라하지 않기!!
  • 따라 쓰더라도 장점/단점과 적용 맥락을 이해하고 적용하자
• 내 프로젝트 구조에 적절한 ****아키텍처를 찾거나 만들어 적용해보기!!

2) 1차 선택: 전통 레이어드 계층

사람들이 흔히 하는 방식

• 많은 프로젝트가 패키지를 “도메인 기준”으로 나눈다.

  domain / (controller, service, repository) 처럼 도메인 중심 구조

  • 일반적인 다른 프로젝트 예시 구조

우리 프로젝트와 비교

• 프로젝트 주제: 조건에 맞는 주식들을 조건 검색해주는 앱

• 우리 프로젝트는 도메인이 여러 개 보다는 주식(Stock)이라는 하나의 도메인이 중심이다.

• 여러 외부 api를 정확히 가져오고 비즈니스 로직을 잘 설계하는 것이 우리 앱에서 중요하므로 각 계층의 역할을 나누는 계층형 구조가 유지보수에 유리하다고 판단함

• 계층형 아키텍처 구조

  

  그림) 일반적인 계층형 아키텍처, 자신보다 아래 쪽 계층을 의존하는 형태로 구성되어있습니다.