[알쏠] 설계 구조 리팩토링

해당 프로젝트를 개발하다가, 심사위원분이 우리 프로젝트에서 파일을 잘 못찾으셨던 것을 계기로, 프로젝트 구조를 다시 정리하려고한다.

당시 받은 피드백 ㄱ

현재 구조를 정확히 진단해보자.

..순수 레이어드아키텍처 X (Controller, Service, Repository, Domain.... 등으로 패키지 분리)

아키텍처 레이어(4레이어) :
User Interface(외부통신) - Application(비즈니스로직, 트랜잭션) - Domain(도메인 객체) - Infrastructure(DB연결, 외적 인프라와 연결)
아키텍처레이어 (3레이어) :
- 프레젠테이션 레이어 -> 애플리케이션 레이어 -> 데이터 접근 레이어
- ( Controller ) | ( Service ) | ( Domain | repository..(infra) )

... DDD 아키텍처 X ()

... 클린 아키텍처 X

-> 현재 도메인 중심 패키징 + 부분적 레이어드 + 유스케이스 중심 구조가 셋이 섞여있다.

그렇다면 해당 프로젝트의 최상위 기준을 무엇으로 설정했는가 - 도메인? 레이어? 기능(유스케이스)?
: 도메인 (다만 내부는 통일 X)

그런데 모순적인 점...이자 현재 문제점.
1. 화면 이름은 도메인이아니다.

Mypage, Onboarding과 같은경우는 비즈니스 도메인이 아닌 UI 플로우(화면흐름)이다.

코드를 짤 때, 누가 쓰느냐(화면 기준)이 아닌, 무엇을 다루냐(데이터, 도메인) 을 기준으로 나눠야한다.

2. 의미 없는 폴더 깊이

현재 extra-shift 등은 프로젝트 구조를 합치다보니, `controller` 폴더 안에 파일하나, `service` 폴더 안에 파일 하나. 구성이 이렇다.

이건 정리를 위한 정리가 되어버려, 폴더를 클릭해서 그 안에 들어가는 행위(Depth)가 추가적인 인지 비용으로 들어간다.

파일이 5개~10개 처럼 많은게 아니라면, 굳이 프로젝트 폴더를 또 만드는것은 좋지않아보인다.

1) 레이어드 아키텍처

controller 
service
domain
repository

위와같은 전통적 구조이다. 지금까지 실습했던 코드들이랑 비슷하다.

내 프로젝트와 비교해보자.

Schedule을 보면 그안에 생성, 수정, 대타, 추가인력... 등등 매우 많은 기능이 존재한다.

이렇게되면 각기능별 경계가 무너지고, 확장 가능성을 고려하였을때 매우 좋지않다.

나중에 레포지토리 디렉터리안에 한 30개있으면 찾는것도 어우.. 일이다.

2) DDD (Aggregate, / Bounded Context)

schedule
 ├─ domain
 │   ├─ model
 │   ├─ service
 │   ├─ repository(interface)
 ├─ application
 ├─ infrastructure

DDD : Domain Driven Design

ddd는 도메인 주도 설계의 약자. 복잡한 소프트웨어 시스템을 구축할 때, 도메인에 초점을 맞추어 설계하는 방법론이다.

지금 당장은 도메인 규칙이 완전히 안정되지않았기에, 이를 진행하면안될듯.

3) 클린 아키텍처 / 헥사고날

현실적으로, 인터페이스 엄청늘어나고(파일수도 같이늘어남),,, 일단 둘다 잘 모르는 아키텍처 패턴이다.

그렇다면 어떤걸 도입하면 좋을까?

: 관련 된건 한곳에 다 때려박되, 성격별로 큰 방만 나눠주자.

도메인 중심 + 유스케이스 하위 모듈(기능) + 얕은 레이어드

좋은 설계란?

1. 폴더 이름만 봐도 역할이 보여야함

2. 쉽게 테스트가 가능해야함

3. 새 기능 추가 시 어디에 넣을 지 고민이 없어야함

4. 신입이 와도 이해 금방하고, 프로젝트에 참여할 수 있어야함.

도메인 내부에서는 유스케이스(기능)단위로 묶고, 그안에서 얕은 레이어드 유지~!

참고한 블로그