Page History
...
우리가 개발한 API를 포함하여 비공개 API 또는 파트너쉽 API등 다양하게 얽혀있는 의존 관계를 어떻게 표현하고 설명할수 있을까요?
도메인 주도개발에 이야기하는 컨텍스트 맵핑을 이용하여 API의 의존관계를 표현하는 방법에대해 새로운 아이디어에대해 알아보겠습니다.
공개호스트 - OpenHostService
이 프로토콜은 공개가 되어있고 API화가 이용하기위한 문서화가 잘되어 있다. 있으며 이것을 이용하는 팀은 상류의 상류 API를 그대로 이용한다이용을 해야합니다.
| draw.io Board Diagram | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
페이스북의 공개된 API를 이용하여 로그인 기능을 만들거나 정부 OpenAPI를 이용하여 기능을 개발하는경우
개발팀은 제공되는 API를 그대로 준수하고 따릅니다.
상류 제공 API팀은 이 기능을 통해 무엇을만드는지 관심이 없을수도 있습니다전체 의견을 수렴해 기능개선을 할수도 있지만 특정팀의 의견을 기능변경을 하지 않습니다.
순응적 패턴
언제 무엇을 받게될지 상류(Upstream)인 공급자(Provider)가 주로 결정을 하지고
이것을 제공받는 하류(DownStream)팀은 상류 스트림을 준수합니다. 하지만
공개호스트와는 다르게 하류팀의 요구사항을 받아들이기도합니다.
draw.io Board Diagram border true diagramName UpStream simpleViewer false width links auto tbstyle top lbox true diagramWidth 266 revision 7
다양한 운행 이용기록을 챗봇을 통해 표현하고 이것을 이용하고자 할때
챗봇개발팀은 이용기록을 제공하는 다양한 버티컬팀의 기능을 이용하지만 때때로 개선을 요청할수도 Cafe24 API를 통해 상품 정보를 제공받기로한 경우 기존 제공되는 API를 그대로 이용할수 있습니다.
하지만 협약관계 또는 상류의 기능이 오류가있거나 개선이 필요할시 공급받는 다운스트림에서 개선요청을 할수도 있습니다.
반부패계층 - AntiCorruption Layer
...
대신에 수행할 수 있는 작업은 다음과 같이 업스트림 경계 컨텍스트를 이용하고
컨텍스트의 모델을 부패 방지 레이어를 통해 추가하여 자체 요구 사항에 맞는 모델로 변환하는 것입니다.
...
draw.io Board Diagram border true diagramName 파트너쉽 simpleViewer false width links auto tbstyle top lbox true diagramWidth 427 revision 2
상담기능을 위한 채팅API가 존재하며 개발팀이 존재하고 그것을 이용하여 채팅시스템을 개발하는 유일한 내부팀이 있다고 가정해봅시다.
이 경우 파트너쉽 관계로 함께 성장하거나 함께 망할수 있는 관계로 가장 적극적으로 지원할수 있습니다.
추후 서로의 의존성이 줄어든다고 하면 다른 관계로 맵핑관계가 변경될수 있습니다.
내부가 아닌 외부관계의 예를 추가로 하자면외부사 관계의 예를 하나더 들어봅시다.
카카오톡의 알림톡/친구톡 API는 파트너사를 통해서만 기능이 구현되고 파트너사가 시장을 적극적으로 확장하게됩니다.
이 경우도 파트너쉽관계로 표현될수 있습니다. 파트너사가 시장개척을 못하면 상류기능도 함께 망하는 구조입니다.내부 파트너쉽은 의존관계에의해 다른관계가 될수 있지, 이경우 이익관계에의해 조정되거나 변경될수 망할수 있습니다.
자사간 팀간 파트너쉽 관계는 아키텍처변경에 의한 의존도가 변경시 맵핑관계가 변경 될수 잇지만
외부간 파트너쉽 관계는 자사 이익관계에 의해 변경될수도 있습니다.
API 관계를 맺는 위 요소를 이용하여 복잡하게 엃혀있는 API를 통한 관계중심구성도를
이용하는 API의 관계중심의 구성도를 가상의 CS서비스를 중심으로 작성을 시도 해보겠습니다.
...
- CS기능이 시작됨으로 마케팅기능을 이용할수 있으며 CS의 최종 BM은 CS가 아닌 마케팅을 통한 BM이다. 그래서 두개의 팀은 파트너관계로 설정되어있다.
- 우리는 메시지팀이 있으며 이 팀은 카카와 라인의 채널을 이용하여 일괄된 상담 API를 제공한다.
- 메시지팀은 라인의 OpenAPI를 그대로 이용하지만, 카카오의 경우 이것을 이용할수 있는 파트너고객사로 기능을 요청하기도한다.
- 우리는 CS팀에서 발생한 데이터를 통해 세그멘테이션을 하고 페이스북에 피드를 보내거나 광고를 집행할수가 있다.
다양한 외부 채널(API)을 연동하고 하나의 채널인 것처럼 보여야하는 옴니채널 개발에 고민을 하는 개발사라고하면 이러한 복잡한 API이용 관계를 컨텍스트 맵핑을 활용해 표현할수 있습니다.
물론 이것은 자사의 서비스가 다양한 API로 구분되어있을때도 적용할수 있습니다.
이 아티컬은 DDD의 컨텍스트 맵핑 아이디어를 베이스로 하며, API 의존관계를 표현할때도 심플하게 이용할수 있습니다.
우리가 활용하는 API가 도메인의 부가기능이 아니라 핵심기능에 가깝다라고 한다면 중요하게 표현해야하는 요소입니다.
활용 API가 오픈API인지? 협약에의한 API인지? 우리 개발팀의 리소스와 상관없이 외부 업스트림 API가 유지 불가에 가까운지?
하지만 더 중요한것은 기능개선 아이디어가 어떠한 API의존성을 가지고 있는지? 개선지점을 모른다고하면 프로덕트의 개선 시도는 어려울수 있습니다.
컨텍스트 맵핑에 대한내용은 아래 링크를 추가로 참고합니다DDD에서 컨텍스트간의 관계를 표현하는 컨셉인 ContextMapping을 참고하였습니다.
...