마이그레이션 계획 #37
Description
Goal
현재 혼용되어있는 파일 및 패키지가 많아 이를 역할별로 분리하려고 함
Acceptance Criteria
api : /api 로 모두 모으는 것이 1차적인 목표.
-
/api로 모든 핸들러 이동 - http 헤더 작성 유틸 생성/적용
/request: 현재 사실상 모든 원격호출을 담당하는 것 같음.지금은 그렇지 않지만 하위 레이어의 서비스 함수들을 /reqest에서 담당할 것 같은 걱정이 있음.
-
request를client로 수정 - 현재 각 함수별로 엔드포인트를 하드코딩하는 방식으로 진행되는데,
client는 http timeout 관리, 헤더작성, 에러 const 동기화의 역할만 맡고 함수 엔드포인트 등은 DI 로 해결(오버엔지니어링이 될까 고민중) - ovn-client 파일
/service/network.go를/client/로 이동
예시)
// endpoints.go - path 상수만 분리
const (
EndpointCreateVM = "/createVM"
EndpointDeleteVM = "/DeleteVM"
EndpointStartVM = "/BOOTVM"
EndpointForceShutdown = "/forceShutDownUUID"
)
service/: 순수한 서비스 함수를 넣을 얘정, 결과적으로는 DI, 값 파싱, infrastructure 관리의 로직
- ssh key gen, guacamole config 와 같은 함수들을
/pkg로 이전, service -> pkg 를 참조하는 구조 -
service/vm상의 함수들을 역할별로 분리
pkg/ : 도메인 특화 혹은 util 함수를 각각 가짐. ** 하위 의존성이 없는 파일들의 모음 **
- sshKeygen
- password encryption
- Core, guacamole 등 도메인 특화 작업(원자적인) , 해당 함수들을 service 에서 가져와서 쓰게 할 예정
고민
현재는 DB.Con 을 가지는 패키지를 만들고, pkg/{domain}/{model} 와 같이 pkg 별로 디비 로직을 관리할 예정.
추후에 pkg 내부에서 db 로직을 서로 참조하는 등으로 발전되면 repository로 분리할 듯.(현재 기준에서는 오버엔지니어링 같음)
예상구조
KWS_Control/
api/ → HTTP handler, req/resp 모델, 응답 헬퍼
client/ → CoreClient, CmsClient (transport만)
core/
client.go
endpoints.go
cms/
client.go
endpoints.go
service/ → 오케스트레이션, ControlContext 관리
pkg/ (or internal/)
ssh/
guacamole/
crypto/
structure/ → 도메인 모델 (현재 유지)
startup/ → 초기화 (현재 유지)
util/ → logger (현재 유지 또는 pkg로)
Notes
해당 이슈는 의견에 따라 자유롭게 수정될 예정입니다.
테스크를 진행할때에는 서브 이슈를 만들고, 체크박스를 선택해주세요