[Aqqle] API pakage 구성

기획없이 그냥 생각나는대로 만들다 보니 패키지 구성이 애매하다.

여러도메인이 서비스를 공유한다 라는 컨셉이긴한데 공유할 일이 있나 싶기도 하고 작업한지가 오래되서 첨에 무슨생각으로 만들었는지도 가물 가물 

아무튼 aqqle 는 1번 구조로 설계되어 있는데 나중에 수정하게 될 수 도.. 

 

 

1. service를 shop과 같은 레벨에 배치:

com.example.project
├── shop
│   ├── controller
│   ├── domain
│   ├── dto
│   └── repository
├── service
└── config

장점:

• 서비스 계층의 재사용성:
  • service 패키지는 여러 도메인(shop, order, user 등)에서 공통적으로 사용할 수 있는 로직을 포함할 수 있음.
• 계층 분리 명확화:
  • 서비스 계층을 독립적으로 관리함으로써 비즈니스 로직이 컨트롤러나 도메인에 의존하지 않게 설계 가능.

단점:

• 복잡성 증가:
  • 각 도메인(shop, order 등)별로 서비스 클래스가 많아질 경우 관리가 어려워질 수 있음.
• 도메인 컨텍스트 혼란:
  • 특정 도메인에만 관련된 서비스가 service에 섞이면, 해당 도메인의 경계를 파악하기 어려움.

 

2. service를 shop 내부에 배치:

com.example.project
├── shop
│   ├── controller
│   ├── domain
│   ├── dto
│   ├── repository
│   └── service
└── config

장점:

• 도메인별 응집성:
  • 도메인 관련 클래스(controller, service, repository 등)가 한 곳에 모여 있어 명확한 경계를 유지.
• 확장성:
  • 새로운 도메인을 추가하거나 기존 도메인을 수정할 때 영향을 최소화.

단점:

• 서비스 재사용성 저하:
  • 특정 도메인에 종속적인 구조로 인해 다른 도메인에서 해당 서비스를 재사용하기 어려움.

---

추천

• **도메인 중심 설계(DDD)**를 따르는 경우, 각 도메인(shop, order 등) 내에 서비스 계층을 두는 것이 더 적합합니다. 도메인 내부에 비즈니스 로직을 응집하여 관리할 수 있기 때문입니다.
• 반면, 서비스 계층이 여러 도메인에서 공통적으로 사용될 경우, service를 최상위 레벨로 독립적으로 구성하는 것이 좋습니다.

결론

• 프로젝트 규모가 작거나 중간 규모라면 shop.service와 같이 각 도메인 내에 service를 두는 방식이 관리하기 더 쉬울 가능성이 높음
• 대규모 프로젝트이거나 여러 도메인이 동일한 비즈니스 로직을 공유한다면 com.example.project.service와 같은 독립 패키지를 고려.