Add AppServe

[seungkyua]

appserve 추가

ORM 개념에 맞추어 중복이 되는 repository 의 struct 와 domain 의 struct 를 하나의 domain struct 로 통일
domain struct 의 경우 tks-client 에서도 response 값으로 사용됨
1:N 일 경우 Cascading Loading 적용

[ktkfree]

음... 고민했었던 내용입니다.
여러 고민끝에 현재의 구조는 DAO와 DTO 를 구분하는 방향으로 아키텍처를 설계하였습니다.

DB 를 추상화하는 repoistory layer 를 완전히 구분하여 DB ORM 을 위한 객체를 디자인하였고,
repository <> usecase <> transport <> external 까지의 Data 전송을 DTO 로 구분하였습니다. ( 현재는 external 은 VO 느낌의 다른 객체(API명_Response)로 표현됩니다. )

아키텍처에 정답은 없고 말씀하신 구조가 golang 에 더 적합한게 아닌가 매번 고민하� 부분이지만, 3-layer architecture 상에서는 기존의 java application 과 유사한 구조가 좋을것 같다는 판단에 최종적으로 DAO, DTO 를 구분하는 방향으로 설계하였습니다.

API 추가/수정이 항상 유사한 과정을 거치므로 모든 API 의 패턴이 동일한 것이 유리하겠습니다. 논의해보면 좋겠습니다.

[bluejayA]

@seungkyua 이슈와 연결 부탁드립니다 (연결할 이슈가 마땅치 않으면 하나 만들어야 되지 않을까 합니다)

[seungkyua]

DAO 는 Data Access Object 로 지금의 Repository 에 있는 gorm query 문을 의미하면 그대로 구현되어 있고, DTO 는 Data Transfer Object 로 우리가 흔히 말하는 Value Object 로 현재 xxxRequest, xxxResponse 로 구현되어 있습니다.
Domain 객체외에 Repository 에 비슷한 또다른 객체를 만들지 않았다는 뜻입니다.

[ktkfree]

"Domain 객체외에 Repository 에 비슷한 또다른 객체를 만들지 않았다는 뜻입니다."
-> Repository 의 객체와 Domain 의 객체는 생김새가 비슷해보이지만 다른 목적을 가진 객체로 설계하였습니다. DB 와 연관되는 객체는 Repository 내에서만 관리되도록 layer 를 구분함이 목적입니다. �

일단 테스트가 우선이니 merge 합니다.
요 건은 온라인으로 논의해보면 좋겠고, 말씀하신 방향이든 기존의 방향이든 "모든 API 의 동일한 패턴화"가 드리고 싶은 말씀입니다.