클린 아키텍처를 실제로 API 설계에 적용하는 경우의 구성을 생각했기 때문에 정리.
깨끗한 아키텍처 구성 요소
종속성은 항상 단방향 엔티티
코어 로직 작성 종종 데이터 모델이 설명됩니다. DB에 데이터를 저장할 때 인터페이스를 주입한다. 사용 사례
응용 프로그램 특정 규칙 만들기 순서를 기술. 로직 종속 제어 구문은 유스 케이스에 설명되어 있습니다 인터페이스 어댑터
외부와의 접속. 입력을 받고 유스 케이스 함수에 흘린다 APIHandler, DBManager 등 프레임워크 & 드라이버
Router EntryPoint 참고 :
htps : // 코 m / 히로 타칸 / MS / 698c1f5773 go로 API를 작성할 때 소스 코드 구성
src
entity
로직을 작성한다. usecase로부터 받은 Interface를 실행해 처리한다. usecase
APIHandler로부터 Request, Repostiry, Interface를 받고 entity를 호출한다. 시퀀스를 기술한다. 시퀀스 만 작성하십시오 사용하는 InterFace는 유스 케이스에 기재되어 있습니다 Interface
APIInterface
외부 API 호출 처리 설명 Repositry
데이터 스토어가 가지는 데이터를 기술. APIHandler
엔드포인트 작성 API 입력 및 Response 구성 드라이버를 받고 usecase 호출
usecase가 사용하는 Repository와 APIInterface를 여기에서 설정 각 InterFace를 묶는다 driver
router.go
라우팅 작성 사용하는 기타 driver를 모두 여기에서 건네준다 datastore.go
Datastore 라이브러리 작성 여기의 인프라는 별로 무엇이든 좋다
redis나 db 등의 액세서
- 필요한 경우이 근처에 둡니다 main.go
driver를 호출한다. 장점
종속성은 항상 단방향이므로 테스트를 쓰기 쉽습니다.
DB, 인프라, API 등의 테스트 모듈은 사용 주름이 효과가 있으므로 한 번 쓰면 테스트가 간단합니다.
DB 등의 기능과 직접 관련이 없는 인프라 교환이 비교적 용이
GCP에 올려 놓기 때문에 Datastore를 사용하든지, 검증을 위해 일단 sql을 사용하면 같은 전환이 편합니다.
단점
의존성을 일방향으로 하기 위해 의존성의 주입을 하고 있기 때문에, 적당히 반대로 읽어들이기 어려운 코드가 완성된다
의존성 주입을 수행하는 인터페이스는 데이터 인프라, 외부 API 발행 등이므로, 사용하는 인터페이스를 미리 규칙화하면 해결할 수 있습니다.
라우팅과 간단한 논리로 처리 할 수있는 규모의 API 만 만들면 중복
Reference
이 문제에 관하여(클린 아키텍처로 API를 설계해 봅니다.), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다
https://qiita.com/y-tac-d/items/b83e2e6605bce0ea5112
텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
