Feat/#76 아키텍처 정의에 따른 패키지 및 클래스 이름 변경

[smartandhandsome]

이슈번호

close: #76
close: #78

작업 내용 설명

패키지 구조 및 아키텍처 정의

리뷰어에게 한마디

아키텍처 정의

각 Layer 정의

1. Presentation Layer: 외부 Client와 상호 작용하는 Layer. 외부에서 들어온 값을 검증한다. 외부의 요청에 알맞는 응답을 보낸다. Service Layer에 있는 적합한 행위를 선택하여 값을 전달한다.
2. Service Layer: 비즈니스 로직을 작성하는 Layer. 필요하다면 @Transactional을 관리한다. 아래에 있는 Implement Layer에서 필요한 행위를 통해 비즈니스 로직을 완성시킨다.
3. Implement Layer: 비즈니스 로직을 작성하기 위한 상세 구현 로직을 갖고 있는 Layer. 여러 Service Layer에서 많이 의존하고 범용성이 높아 재사용성이 많은 Layer. @Component 어노테이션을 붙인다.
4. Infrastructure: 외부의 Data 혹은 통신을 위한 Layer. MySQL, Redis 혹은 S3 같은 Data에 접근, 생성, 수정 등을 담당, 외부 Server와 의 통신, DAO를 갖고 있어야 한다. ex) JpaRepository (X), SimpleJpaRepository (O)

경계간 매핑

1. Client ↔ Presentation Layer: final class OOOHttp 내부 record로 Request, Response가 존재한다. (입력이나 반환 값이 없으면 해당 record 생략, suffix는 Http로 고정)
2. Service ↔ Controller: Controller에서 조작하는 Service의 메서드의 반환 값은 XXXXDto, Controller에서 Service로 데이터를 보낼 때는 커스텀 객체가 아닌 순수 자바가 정의한 클래스로 보낸다. 추후 Service에 전달하는 매개 변수가 많이 진다면 리팩토링 한다.
3. Service, Implement: Domain 객체를 직접 다룰 수 있다.
4. Infrastructure: Entity 따로 두지않고 Repository는 Domain을 의존한다. 외부와 통신하는 Client는 응답 값을 받는 객체로 OOODetail을 둔다. (suffix Detail 고정)

규칙

1. 레이어는 위에서 아래로 참조할 수 있다. ex) Controller → Service → Implement → Infrastructure
2. 레이어의 참조가 하위 레이어를 건너 뛸 수 없다. ex) Controller → Implement 참조 ( X )
3. 상위 레이어는 하위 레이어에 의해 참조할 수 없다. ex) Controller ← Service ( X )
4. 동일 레이어있는 다른 객체를 참조할 수 없다. ex) OOOService → XXXService ( X )
5. 예외적으로 Implement Layer는 동일 레이어에 있는 다른 객체를 참조 할 수 있지만, 가능한 참조하지 않도록 설계한다.

[github-actions]

Test Results

25 files  +2  25 suites  +2   5s ⏱️ ±0s
61 tests +6  61 ✔️ +6  0 💤 ±0  0 ❌ ±0 
61 runs  +5  61 ✔️ +5  0 💤 ±0  0 ❌ ±0 

Results for commit 91fec77. ± Comparison against base commit 212bb16.

♻️ This comment has been updated with latest results.