마이크로 서비스 및 정식 모델

이 사이트 에서 마이크로 서비스에 대해 읽을 때 아래 진술을 보았습니다 . 표준 스키마 란 무엇입니까? 도메인 모델과 같지 않습니까?

Microservices Architecture 패턴은 표준 스키마 개념과 같은 SOA의 다른 부분도 거부합니다.

@ArseniMourzenko 의견에 의지하여 미리 사과하지만 Wikipedia를 읽기 시작하면 Canonical Schema의 의미를 즉시 이해했습니다 .

여기 실제 의심에 초점을 맞춘 OP의 의견

마이크로 서비스 아키텍처에서도 요청 및 응답이 일부 데이터 모델을 준수해야한다고 생각합니다.

일부 데이터 모델은 가능하지만이 기사에서는 두 개 이상의 서비스간에 "공유"또는 "공통"데이터 모델을 언급하고 있습니다.

정식 스키마는 런타임 데이터 변환에서의 서비스를 저장하는 의미 패턴입니다. 또한 코드를 복제하지 않아도됩니다. 그러나 서비스를 외부 데이터 모델에도 연결하고 있습니다. (위 링크 된 Wikipedia 페이지의 다이어그램 참조)

서비스간에 공통적 인 "언어"입니다.

따라서이 기사는 MS가 살고있는 "생태계"와 MS의 총 독립성을 강조하고있는 것 같습니다.

ESB에 대한 언급을 예로 들어 보겠습니다.

또한 ESB 사용을 피하고 마이크로 서비스 자체에서 ESB와 같은 기능을 구현합니다.

ESB는 일반적으로 버스에 연결된 모든 사람에게 공통적 인 엔터프라이즈 데이터 모델 (메시지)을 요구합니다.

따라서 기사로 돌아가서 저자는 MS가 외부 시스템에 대한 연결을 거부 한다는 사실을 지적하고있는 것 같습니다 (및 제약 조건) .

마이크로 서비스는 긴밀한 응집력과 느슨한 결합에 관한 것입니다. 마이크로 서비스 내에서는 긴밀한 응집력이 있지만 마이크로 서비스 간에는 커플 링이 느슨하므로 공유 스키마 또는 데이터 계약을 피하려고합니다. 공통 스키마를 공유하도록 요구하는 방식으로 서로 동기 호출을하는 마이크로 서비스가있는 경우 서비스 경계를 ​​잘못 정의했음을 나타낼 수 있습니다.

마이크로 서비스는 도메인 중심 디자인 용어에서 경계 컨텍스트와 밀접하게 정렬되어야합니다.