Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

draw.io Board Diagram
bordertrue
diagramNamePLAPI
simpleViewerfalse
widthlinksauto
tbstyletop
lboxtrue
diagramWidth301378
revision56

페이스북의 공개된 API를 이용하여 로그인 기능을 만들거나 정부 OpenAPI를 이용하여 기능을 개발하는경우

개발팀은 제공되는 API를 그대로 준수하고 따릅니다.

상류 제공 API팀은 전체 의견을 수렴해 기능개선을 할수도 있지만 특정팀의 의견을 위해 기능변경을 하지 않습니다.


순응적 패턴

언제 무엇을 받게될지 상류(Upstream)인 공급자(Provider)가 주로 결정을 하지고

...

draw.io Board Diagram
width
bordertrue
diagramNameUpStream
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth266
revision7

...

draw.io Board Diagram
width
bordertrue
diagramName반부패계층
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth441
revision67

라인의 메시지 발송( OpenAPI,OHS)과 카카오의 발송 API(폐쇄적,UD)를 함께 이용할수 있는API를 제작해야하고 개발팀에 제공한다고 가정해봅시다.

이런경우 상류 API를 이용은 하지만 부패 방지 레이어를 별도로 구성하여 이것을 이용하는팀의 요규사항에 요구사항에 맞게 새로운 모델로 변환할수 있습니다.


파트너쉽

draw.io Board Diagram
width
bordertrue
diagramName파트너쉽
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth427
revision2

...

API 관계를 맺는 위 요소를 이용하여 복잡하게 엃혀있는 얽혀있는 API를 통한 관계중심구성도를

가상의 CS서비스를 중심으로 작성을 시도 해보겠습니다. 

draw.io Board Diagram
width
bordertrue
diagramNamecontextmapping
simpleViewerfalse
linksauto
tbstyletop
lboxtrue
diagramWidth822
revision1

...

하지만 더 중요한것은 기능개선 아이디어가 어떠한 API의존성을 가지고 있는지? 개선지점을 모른다고하면 프로덕트의 개선 시도는 어려울수 있습니다.

또한 반부패계층이 필요한 경우 모델링을 통합하는것에 이점이 있을수 있으며  공개호스트 또는 순응적 패턴에서 업스트림의 모델을 그대로 이용하는것이 이점이 있을수도 있습니다. 중요한것은 항상 통합해서 부패를 방지하기보다 어떠한 전략적 모델을 채택할것인가? 입니다. 


이 아티컬은 DDD의 컨텍스트 맵핑 아이디어를 베이스로 , 복잡하게 얽혀있는 API 의존관계를 심플하게 표현할수 있는 하나의 아이디어입니다. 


컨텍스트 맵핑의 원문과 경계를 구분하는 방법은 아래링크를 추가로 참고합니다.

...