포트폴리오로 백엔드를 만드는데,
정확히 어떻게 왜 언제 쓰는지 모르는 아키텍쳐를
있어보이려고 갖다붙이기 보다 기본 토대를 탄탄히 해보자는 느낌에서
기본적인 mvc2 방식에서 DDD구조에서 쓰이는 파사드 구조만 조금 떼낸뒤
hexagonal 아키텍쳐에 사용되는 application 단을 사용 해봤다
기본적인 구조는 이렇게 되어있다
domain
최상위 계층으로 도메인 이름으로 패키지를 구성한다
controller
도메인 안의 컨트롤러 패키지로 restController를 모아두고,
request Dto 폴더를 내부에 생성에 dto 관리를 한다.
facade
파사드 패턴으로, 파사드 패키지 안에서만
현재 도메인 외 외부 도메인, 서비스와 교류 해 코드 복잡성을 줄인다.
application
application/inport 는 service interface를 만들어 보관한다.
application/outport 는 외부 레포지토리 인터페이스를 보관한다.
application/service/serviceImpl에 해당 도메인 관련된
비즈니스 로직을 구현한다.
external
외부에서 오는 데이터등을 관리한다.
repository(db) 포함.
왜?
'추후의 확장성만 고려' 한다면 더 용이한 아키텍처가
많겠지만 일단의 목표는 완성과 배포가 우선이기때문에
비교적 단순한 구조를 채택했다.
facade로 여러서비스가 한곳에 엉켜 가독성이 안좋아지는
부분을 막으려고 facade패키지를 따로 추가함.
(2023-10-18 수정)
application단 추가는 reader,store를 들여 오면서
application을 단순히 service라고 표현하기에는 무리가 있다 싶어
변경했다.
service에 '접근'하기때문에 inport(밖에서 안으로 들어온다)
service에서 '호출'하기때문에 outport(안에서 외부인자를 호출)
repository를 reader 와 store로 나누고,
reader는 셀렉트 관련 쿼리,
store는 그외의 쿼리들을 구분하면 서비스에서는 네이밍을
깔끔하게 쓸수 있다.
