오픈 API 또는 공개 API는 개발자라면 누구나 사용할 수 있도록 공개된 API를 의미합니다.
그러면 비공개 API 또는 파트너쉽 API등 다양한 관계에 있는 API를 어떻게 표현하고 설명할수 있을까요?
도메인 주도개발에의 컨텍스트 맵핑을 이용하여 API의 관계에대해 표현해보겠습니다.
공개호스트 - OpenHostService
이 프로토콜은 공개가 되어있고 API화가 잘되어 있다. 이것을 이용하는 팀은 상류의 API를 그대로 이용한다.
페이스북의 공개된 API를 이용하여 로그인 기능을 만들거나 정부 OpenAPI를 이용하여 기능을 개발하는경우
개발팀은 제공되는 API를 그대로 준수하고 따릅니다. 상류 제공 API팀은 이 기능을 통해 무엇을만드는지 관심이 없을수도 있습니다.
순응적 패턴
언제 무엇을 받게될지 상류(Upstream) 공급자(Upstream)가 주로 결정을 하지고 이것을 이용하는 하류(DownStream)은
준수합니다. 하지만 하류팀의 요구를 받아들이기도합니다.
자사의 모빌리티 이용기록을 챗봇을 통해 표현하고 이것을 이용하고자 할때
외부 챗봇개발팀은 이용기록 버티컬팀에게 기능을 개선하거나 요청할수가 있습니다.
반부패계층 - AntiCorruption Layer
순응적 패턴의 경우와 마찬가지로 이 관계의 힘의 균형은 여전히 업스트림 서비스 쪽으로 치우쳐 있습니다.
그러나 이 경우 다운스트림 제한된 컨텍스트는 이를 따르려고 하지 않습니다.
대신에 수행할 수 있는 작업은 다음과 같이 업스트림 경계 컨텍스트의 모델을 부패 방지 레이어를 통해 자체 요구 사항에 맞는 모델로 변환하는 것입니다.
라인의 메시지 발송( OpenAPI,OHS)과 카카오의 발송 API(폐쇄적,UD)를 함께 이용할수 있는API를 제작해야하고 있고 개발팀에 제공한다고 가정해봅시다.
이런경우 상류 API를 이용은 하지만 부패 방지 레이어를 별도로 구성하여 이것을 이용하는팀의 요규사항에 맞게 새로운 모델로 변환할수 있습니다.
파트너쉽
상담기능을 위한 네이버 톡톡 API가 존재하지만 그것을 이용하여 채팅시스템을 작성하는 개발팀이 유일하다고 가정해봅시다.
이 경우 파트너쉽 관계로 함께 성장하거나 함께 망할수 있는 관계로 가장 적극적으로 지원할수 있습니다.
서로의 의존성이 줄어든다고 하면 다른 관계로 맵핑관계가 변경될수 있습니다.
예를 들면 카카오톡의 친구톡 API가 파트너사를 통해 비즈니스 확장이 되었지만, 파트너사를 통해 시장을 이미 확보했기때문에
이 관계를 변경하고 상위업체는 새로운 비즈니스 관계를 만들수 있습니다.
파트너쉽은 언제든 이익관계또는 아키텍처변경에 의해 깨지거나 변경될수 있다란 의미입니다.
여기서는 외부개발사와 파트너쉽을 설명하였으며, 동일회사의 개발팀관계라 할지라도 파트너쉽관계로 설명될수 있습니다.
참고자료