표준 데이터 모델은 엔터프라이즈 통합 패턴에서 서로 다른 데이터 형식을 사용하는 응용 프로그램을 통합할 때 종속성을 최소화하는 솔루션으로 정의됩니다. 즉,구성 요소(응용 프로그램 또는 서비스)는 두 구성 요소 데이터 형식 모두에 독립적인 데이터 형식을 통해 다른 구성 요소와 통신해야 합니다.
여기서 강조해야 할 두 가지. 먼저 이러한 모델은 응용 프로그램 통합 및 서비스 방향의 맥락에서 사용 되었기 때문에 구성 요소를 응용 프로그램 또는 서비스로 정의했습니다. 둘째,여기서 우리는 전송 데이터 형식으로만 사용해야 하는 개념에 대해 이야기하고 있습니다. 데이터 저장소의 내부 구조로 표준 데이터 형식을 사용해서는 안 됩니다.
이론적으로,이점은 매우 명백합니다. 정식 데이터 형식은 응용 프로그램 간의 결합을 줄이고 구성 요소 집합을 통합하기 위해 개발 될 번역 수를 줄입니다. 꽤 흥미로운 권리? 하나의 단일 데이터 모델은 전체 환경과 일련의 사람들(개발자,시스템 분석가,비즈니스 이해 관계자 등)이 이해할 수 있습니다.)누가 주어진 개념의 동일한 비전을 공유 할 수 있습니다.
실용적인 목적을 위해 이러한 모델을 구현하는 것은 거의 효율적이지 않습니다.
사람은 보험 회사의 마케팅 및 지원 부서와 동일한 개념이 아닙니다. 항공 교통 관리 시스템에 대 한 비행 파일럿에 의해 채워졌다 또는 당신의 영공 위에 지속적인 비행 하는 경우에 따라 다른 의미가 있다. 지원팀에 의해 유지되어야 하는 경우에 따라 완전히 다른 표현을 가집니다.
대부분의 컨텍스트에서 정식 데이터 모델을 설계하면 전체 선택적 속성 집합과 필수 속성(예:식별자)이 거의없는 대용량 데이터 모델이 생성됩니다. 그것은 주로 구성 요소 통합을 용이하게하기 위해 설계되었다하더라도,당신은 단지 그것을 복잡하게 할 것이다. 그 동안 모델은 고유의 복잡성(활용 및 관리 측면에서)으로 인해 사용자들 사이에 많은 좌절을 일으킬 것입니다. 또한,커플 링 문제에 관해서는,당신은 단지 그것을 다른 곳으로 옮기고 있습니다. 대신 하나의 구성 요소 데이터 형식에 결합되는,당신은 긴밀하게 매우 자주 변경 될 전체 가로 및 주제에 의해 사용되는 하나의 공통 데이터 형식에 결합된다.
간단히 말해서,대부분의 상황에서 표준 데이터 모델은 반 패턴으로 간주되어야합니다. 여전히 데이터를 교환하는 두 구성 요소 간의 종속성을 최소화 할 것을 고려하는 것보다 다른 옵션은 무엇입니까?
도메인 기반 디자인은 경계 컨텍스트의 개념을 도입하는 것이 좋습니다. 경계 컨텍스트는 단순히 모델이 다른 경계 컨텍스트와 명확한 경계를 사용하여 적용되는 명시 적 컨텍스트입니다. 조직에 따라 제한된 컨텍스트는 개체가 사용되는 기능 도메인을 참조 할 수 있으며 개체 상태 자체를 참조 할 수 있습니다.
이 경우 표준 데이터 모델은 다음 다이어그램에서 노란색 부분일 뿐입니다:
또한 중요한 것은 두 문맥 사이의 교차점(ㅏ 과 비,비 과 씨,씨 과 ㅏ). 한 컨텍스트에서 다른 컨텍스트로 하나의 객체 표현을 매핑하는 방법은 무엇입니까? 두 컨텍스트에서 공유해야 하는 명시적 특성은 무엇입니까? 두 컨텍스트 간의 일반적인 비즈니스 제약 조건은 무엇입니까? 이러한 질문은 여전히 횡단 팀에 의해 대답해야하지만 비즈니스 관점에서 볼 때이를 제기하는 것이 합리적입니다. 잠재적으로 반대되는 컨텍스트를 통해 공유되는 하나의 단일 디스크 파티션의 경우 항상 그런 것은 아닙니다.
그럼에도 불구하고 다른 컨텍스트와 공유되지 않는 부분(흰색)에 대해서는 엔터프라이즈 데이터 모델의 일부가되어서는 안됩니다. 당신은 실용적이어야합니다. 예를 들어 하위 집합이 특정 도메인에 특정한 경우 도메인 전문가가 직접 모델링해야 합니다.
하지만 한 가지 핵심 과제는 이러한 경계 컨텍스트를 식별하는 것이며 콘웨이의 법칙을 상기시키는 것이 가치가있을 수 있습니다:
시스템을 설계하는 모든 조직은 필연적으로 구조가 조직의 커뮤니케이션 구조의 복사본 인 디자인을 생성합니다.
제한된 컨텍스트가 반드시 현재 조직에 매핑 될 필요는 없습니다. 예를 들어,경계 컨텍스트는 여러 부서를 포함 할 수 있습니다. 조직 사일로를 깨는 것은 여전히 대부분의 기업에 대한 목표가되어야한다.
또한 부패 방지 계층의 개념을 소개합니다. 이 패턴은 데이터 품질 문제 등을 방지하기 위해 이전 시스템과 새 시스템 사이에 중개 계층을 도입하여 레거시 마이그레이션에 대한 솔루션을 참조 할 수 있습니다.). 그러나 우리가 부패에 대해 이야기 할 때 우리의 맥락에서 그것은 단기 문제를 해결하기 위해 소개 할 수있는 데이터 모델링 부채와 관련이 있습니다.
우리의 예를 두 시스템을 관리하는 위탁 받는 상태의 PLM 일(일부는 실제 품목 생산 또는 구매하고 조립처럼 헬리콥터 로터에 대한 인스턴스). 하나의 레거시 시스템(시스템마라고 부름)이 설계 단계 관리를 담당하고 있으며 유지 관리 단계를 관리하려면 새 시스템(시스템즈라고 부름)을 구현해야 합니다. 전체 응용 프로그램 풍경은 그것을 인식하지 못하는 시스템을 제외하고 동일한 공통 부분 식별자(부분)를 공유합니다. 대신 시스템 테마는 자체 식별자 인 시스템 에이드를 관리합니다. 이 패키지에는 주 프로그램 바이너리와 미리 컴파일된 대수 및 자동 로드 모듈이 전부 들어있습니다.
이것은 피해야 할 일반적인 실수입니다. 당신은 단순히 때문에 단기 상황의 데이터 모델을 손상.
이 패턴은 여기서 해결책이 될 수 있습니다. 전체 평가는 별 5(5)개입니다-1 리뷰에 기반함.이 파일은 실행가능한 파일입니다. 그러면 파티드와 시스템 에이드 사이의 번역을 관리하는 중개 계층에 달했을 것입니다.
우리의 주제에 적용,두 개의 서로 다른 경계 컨텍스트 사이의 레이어를 구현 하기 위해 적용 합니다. 구성 요소는 자체 경계 컨텍스트의 일부가 아닌 다른 구성 요소를 호출하는 방법을 인식하지 못합니다. 대신 구성 요소는 자신이 속한 경계 컨텍스트의 데이터 형식에 대해 자체 데이터 구조를 매핑하는 방법만 알고 있습니다.
그건 그렇고,이것은 엄지 손가락의 규칙입니다. 구성 요소는 하나의 경계 컨텍스트에만 속해야합니다. 이 때문에 디디디디 는 마이크로서비스 아키텍처에 매우 적합합니다. 세분화된 세분성으로 인해 이 규칙을 쉽게 준수할 수 있습니다.
요약하자면,표준 모델은 대부분의 경우 반 패턴으로 간주되어야합니다. 컨텍스트 간에 명시적 경계가 있는 컨텍스트 당 하나의 모델을 의미하는 경계 컨텍스트 개념을 구현해야 합니다. 서로 다른 경계 컨텍스트의 일부인 두 구성 요소는 데이터 모델링 손상을 방지하기 위해 손상 방지 계층을 통해 통신해야 합니다.