현재의 증거가 정식 데이터 모델에 대한 문맥 적 채택을 지원합니까?

"정규적인"아이디어는 소프트웨어에 널리 퍼져 있습니다. Canonical Model , Canonical Schema , Canonical Data Model 등과 같은 패턴 은 개발 과정에서 반복해서 나타나는 것 같습니다.

많은 개발자와 마찬가지로, 나는 당신 이 정식 모델 이 필요 하다는 기존의 지혜를 비판적으로 따랐습니다 . 그렇지 않으면 매퍼와 번역가 의 조합 폭발 에 직면하게 됩니다. 또는 적어도 내가 하는 데 사용 내가 먼저 다소-악명 읽을 때 몇 년 전까지 만해도 그렇게 없음 신뢰의 EF 투표를 :

정식 데이터 모델의 추구를지지했던 가설은 일단 아이디어가 실행되면 발견 될 요소를 포함하지 않았으며 포함 할 수도 없었습니다. 우리는 수년간의 시행 착오를 통해 표준 데이터 모델이 사용될 수있는 각각의 개별 상황에 대해 별도의 모델을 사용하는 것이 가장 복잡한 접근법이며, 가장 비용이 적게 드는 방법이며 유지 관리 성과 확장 성을 높이는 방법이라는 것을 발견했습니다. 상황에 맞는 모델을 사용하는 응용 프로그램 및 엔드 포인트의 표준이며, 표준 모델이하는 소프트웨어 엔트로피를 장려하지 않는 접근 방식입니다.

이 글은 주장을 뒷받침 할만한 어떠한 증거도 제시하지 않았지만 대안을 시도하기에 충분히 오랫동안 CDM 접근법에 의문을 제기하게되었으며 결과 소프트웨어는 문자 그대로 또는 비 유적으로 폭발하지 않았다. 그러나 이것이 완전히 고립 된 것은 아닙니다. 나는 운이 좋았을 수도있다.

소프트웨어 시스템이나 아키텍처에서 정식 모델과 상황에 맞는 모델의 실제적이고 장기적인 영향에 대한 진지한 연구가 있었습니까?

또는, 너무 빨리 물어 보지 않으면 개발자 / 건축가가 CDM에서 독립적 인 상황 별 모델로 또는 그 반대로 전환하는 개인적인 경험에 관한 글을 쓰게되거나 생산성, 복잡성 또는 신뢰성과 같은 것들에 대한 실제적인 영향은 무엇입니까?

서로 다른 수준의 차이점, 즉 단일 응용 프로그램에서 동일한 모델을 사용하는 것과 응용 프로그램 시스템 또는 전체 엔터프라이즈에서 사용하는 것과 같은 모델은 무엇입니까?

(사실, 제발, 전쟁 이야기는 환영하지만 추측은 없습니다.)

EF Vote of No Confidence 기사에 대한 응답으로 Tim Mallalieu는 다음과 같이 씁니다.

우리는 사람들이“표준 스키마”에 XSD 사용을 복음화하던 시절로 돌아가는 것을 권장하지 않습니다. 나는 사람들이 이것이 다루기 쉽다고 생각하지 않는다. 그러나 우리가 믿는 것은 많은 도메인 모델을 설명 할 수있는 단일 메타 모델 (원하는 경우 EDM)을 사용하는 것이 바람직하며 단일 문법을 통해 모든 서비스에 공통 서비스를 제공 할 수 있다는 것입니다 주어진 도메인 모델.

예를 들어, 600 개의 테이블이있는 데이터베이스에 대해 작성 될 애플리케이션을 고려하십시오. 이 앱에 600 개의 엔티티 유형이있는 단일 모델이 있어야한다고 생각합니까? 아니요… 또한, 특정 도메인 엔터티 (예 : 고객)가 해당 앱에서 하나의 모양 만 가지고 있으며이 모양이 전체 엔터프라이즈의 표준 모양이어야한다고 생각합니까?

Canonical Model에 대한 Wikipedia 기사는 Enterprise Service Bus , Service-Oriented Architecture 및 CORBA 와 같은 것을 더 이상 거의 이야기하지 않는 것처럼 참조합니다. 이들은 모두 기업의 데이터 확산 및 통신 문제에 대한 해결책으로 제시되었습니다 . ^TM 성공 했습니까? 아니면 자신의 무게로 무너 졌습니까?

당신은 개인적인 경험을 요청했기 때문에 하나를 드릴 것입니다. 항공 우주 산업에서는 원격 측정을 많이 사용합니다. 원격 측정 시스템의 문제점 중 하나는 서로 다른 테스트 범위가 의미있는 방식으로 테스트 데이터를 서로 통신 할 수있는 방법을 찾는 것입니다. 공통 용어의 데이터 사전을 정의하려고 시도 할 때까지이 문제는 충분히 단순 해 보입니다.

"고도"는 무엇을 의미합니까? 지상의 높이입니까, 아니면 해발의 높이입니까? 잠수함에 대해 이야기한다면? 그런 다음 고도가 아닌 깊이입니다. 육군에게 "전송"이라는 단어는 지상 차량과 달리 레이더 접시를 언급 할 때 다른 의미를 갖습니다. 항공기가 구르는 날개 표면을 일부 비행기에서는 "aileron"이라고하고 다른 비행기에서는 "elevon"이라고합니다.

그것은 뒤 따르는 문제의 산에 대한 힌트 일뿐입니다. 데이터 통신에 대한 표준이 있지만 모든 테스트 범위는 다르며 요구, 목표 및 우선 순위가 다릅니다. 동일한 범위의 프로젝트마다 표준이 다를 수 있습니다. 이러한 이유로, 테스트 범위는 솔루션이 모든 것을 단일 모 놀리 식 시스템으로 대체하는 것이 아니라 간단한 통신 프로토콜 에 동의하고 한 범위의 어휘에서 다른 범위로 변환하는 방법을 제공함으로써 해결책이 제공 될 것임을 이해합니다 .

대기업이 직면 한 문제는 비슷합니다. 마이크로 소프트는 모 놀리 식 용어로 생각하는 경향이 있지만, 그 회사는 대체로 모 놀리식이 기 때문입니다. 서로 다른 문화와 사업 방식을 가진 다른 회사들 사이 (또는 같은 회사의 서로 다른 부서 간) 사이에서 의사 소통을해야하는 즉시, 그들 모두를 지배 하는 하나의 고리. ^TM이 즉시 분해되기 시작합니다.