계층형 아키텍처(Layered Architecture)
src/
└── controller/
└── service/
└── repository/
모든 api가 한곳에 다들어감으로 단순하거나 작은 규모에서 사용
도메인 기반구조(Domain-Based Structure)
src/
└── product/
└── controller/
└── service/
└── repository/
└── notification/
└── product_notification/
└── controller/
└── service/
└── repository/
└── product_user_notification/
└── controller/
└── service/
└── repository/
이런식으로 도메인 별 계층구조를 나눌 수 있다.
도메인별로 명확한 분리된 기능 -> 비즈니스 로직이 좀 더 복잡해질 때 (중간규모)
DDD (Domain-Driven Design) 기반 구조
src/
└── application/ // 애플리케이션 로직, 유스케이스 처리
└── domain/ // 엔티티, 밸류 오브젝트, 리포지토리 인터페이스
└── model/
└── product/
└── notification/
└── infrastructure/ // 데이터베이스나 외부 시스템과의 통신 구현
└── persistence/
└── product/
└── notification/
└── webapi/ // API 엔드포인트 및 컨트롤러
└── product/
└── notification/
도메인이 분리된 것을 나아가서 더욱더 복잡한 대규모 프로젝트에서 사용
비즈니스로직, api, JPA(DB), 외부시스템연동 이렇게 4가지 부분으로 나눠서 build따로함
각각의 모듈 따로 배포 -> 유지보수 극대화
이러한 DDD 개념은 클릭 아키텍처 , 헥사고날 아키텍처로 확장될 수 있다.
개인적인 관점
프로젝트의 규모와 개발 시간에 맞는 적절한 파일 구조를 선택하는 것이 모두에게 효율적이고 만족스러운 결과를 가져온다고 생각한다.
또한, DDD를 기반으로 모듈을 분리하고 독립적으로 배포할 수 있다면, 유지보수성을 높이는 것뿐만 아니라, 발생하는 문제에 대해 빠르고 효과적으로 대응할 수 있다고 본다.
아래는 DDD를 학습하며 정리한 나의 관점이다.
○장점으로 생각되는 내용
●시간감소
예를들면 배포문제에도 어느 부분이 문제가 생겼을 때 그 파트(특정모듈)만 고치고 다시 배포하면 되기 때문에 전체를 배포할 필요가 없게된다.
++업데이트, 확장 가능
●팀간 병렬 작업
같은 코드에서 작업하는게 아닌 다른 모듈에서 작업하기 때문에 시간단축
●에러시 장애 격리
전체 영향을 주지 않고 특정 모듈만 롤백 가능
●트래픽이 많은 모듈만 별도로 모니터링 및 성능 극대화 가능
●레거시 시스템과의 시스템 통합시 부분적으로 통합하는 점진적인 개발 가능
○단점으로 생각되는 내용
이론적으로는 뭐든 좋다. 하지만 개인적으로 여러 개발자 유튜브나 현직자들의 의견을 받아봤을 때 신입으로써는 제약이 좀 많다는 생각이 든다.
●높은 학습 난이도(설계의 복잡성)
처음 클린 아키텍처를 적용하려 도전했을 때 난이도가 높다는 생각이 들었고 시간내에 완성이 불가능 하다고 판단해 도메인 기반구조를 적용시켰던 적이 있다.(클린 아키텍처 같은 경우 국내 강의도 많이 없었다.)
따라서 차근차근 msa에 먼저 익숙해진 후 도전해보는것이 낫다고 사료되었다.
