나는 최근 Hohpe와 Woolf의 엔터프라이즈 통합 패턴, SOA에 대한 Thomas Erl의 저서 중 일부를 읽고 Udi Dahan et al.의 다양한 비디오와 팟 캐스트를보고 있습니다. CQRS 및 이벤트 구동 시스템.
작업장의 시스템은 높은 커플 링으로 인해 어려움을 겪습니다. 각 시스템에는 이론적으로 자체 데이터베이스가 있지만 시스템 간에는 많은 조인이 있습니다. 실제로 이것은 모든 시스템이 사용하는 하나의 거대한 데이터베이스가 있음을 의미합니다. 예를 들어 고객 데이터 테이블이 하나 있습니다.
내가 읽은 대부분은 각 시스템이 데이터베이스 만 사용하고 한 시스템에 대한 모든 업데이트가 메시징을 사용하여 다른 시스템으로 전파되도록 데이터 비정규 화를 제안하는 것으로 보입니다.
이것이 SOA의 경계를 강화하는 방법 중 하나라고 생각했습니다. 각 서비스에는 자체 데이터베이스가 있어야하지만 이것을 읽었습니다.
/programming/4019902/soa-joining-data-across-multiple-services
그리고 이것이 잘못된 일임을 제안합니다.
데이터베이스를 분리하는 것은 시스템을 분리하는 좋은 방법처럼 보이지만 이제는 약간 혼란스러워합니다. 이것이 좋은 길입니까? SOA 서비스, DDD 경계 컨텍스트, 애플리케이션 등에서 데이터베이스를 분리해야한다고 권장 한 적이 있습니까?
답변
분리는 실제로 분리가있는 경우에만 작동합니다. 주문 시스템이 있는지 고려하십시오.
- 테이블 : 고객
- 테이블 : 주문
그것이 당신이 가진 전부라면, 그것들을 분리 할 이유가 없습니다. 반면에, 이것이 있다면 :
- 테이블 : 고객
- 테이블 : 주문
- 테이블 : CUSTOMER_NEWSLETTER
그런 다음 ORDER와 CUSTOMER_NEWSLETTER는 완전히 별개의 두 모듈 (주문 및 마케팅)의 일부라고 주장 할 수 있습니다. 아마도 이들을 별도의 데이터베이스 (각 테이블마다 하나씩)로 이동하고 두 모듈 모두 자체 데이터베이스의 공통 CUSTOMER 테이블에 대한 액세스를 공유하도록하는 것이 좋습니다.
이렇게하면 각 모듈이 단순화되지만 데이터 계층의 복잡성이 증가합니다. 응용 프로그램이 점점 커짐에 따라 분리가 유리하다는 것을 알 수 있습니다. 실제로 서로 관련이없는 점점 더 많은 “데이터 섬”이있을 것입니다. 그러나 모든 모듈을 교차 절단하는 데이터가 항상 있습니다.
다른 물리적 데이터베이스에 배치하기로 한 결정은 일반적으로 백업 빈도, 보안 제한, 다른 지리적 위치로의 복제 등과 같은 실제 제약 조건을 기반으로합니다. 분리 문제 때문에 테이블을 다른 물리적 데이터베이스로 분리하지는 않습니다. 다른 스키마 또는 뷰로 더 간단하게 처리 할 수 있습니다.
답변
내가 일하는 곳에 ESB가 있습니다6 개의 서로 다른 응용 프로그램 (또는 “종료점”이라고 말해야 함)이 연결되어 있습니다. 이 6 개의 애플리케이션은 2 개의 데이터베이스 인스턴스에서 3 개의 서로 다른 Oracle 스키마와 함께 작동합니다. 이러한 응용 프로그램 중 일부는 관련이 있기 때문에가 아니라 외부 공급자가 데이터베이스 인프라를 관리하고 새 스키마를 얻는 데 시간이 오래 걸리기 때문에 동일한 스키마에 공존합니다 (물론 DBA 액세스 권한도 없음) … 한 시점에서 기존 스키마를 “임시”재사용하여 개발을 계속할 수있을 것으로 생각하는 데 실제로는 시간이 너무 오래 걸립니다. 데이터의 “분리”를 시행하기 위해 고객의 경우 테이블 이름 앞에 “CST_”가 붙습니다. 또한, 우리는 절대적인 변화가 불가능한 몇 가지 유효한 이유로 스키마를 사용해야합니다. 물론 항상 발생하는 것처럼 “임시”
우리의 다른 응용 프로그램은 각각의 데이터베이스 스키마에 연결하고 자체 PL / SQL 패키지와 함께 작동하며 응용 프로그램 도메인 외부의 테이블 / 데이터와 직접 상호 작용하는 것을 절대 금지합니다.
ESB에 연결된 애플리케이션 중 하나가 도메인 외부에서 정보를 필요로하는 경우 ESB의 관련 서비스를 호출하여 해당 정보가 실제로 동일한 스키마에있는 경우에도 이론적으로는 약간의 조인 명령문이 필요합니다. SQL 요청 중 하나입니다 .
우리는 애플리케이션 도메인을 다른 스키마 / 데이터베이스로 분할하고 ESB의 서비스가 발생할 때 여전히 올바르게 작동하도록하기 위해 그렇게합니다 (크리스마스가 곧 손가락을 고집하고 있습니다)
이제는 외부에서 이상하고 끔찍하게 보일 수 있지만 그 이유가 있으며 하나 이상의 데이터베이스가 그렇게 중요하지 않다는 것을 보여주기 위해이 구체적인 경험을 공유하고 싶었습니다. 잠깐만! , 여러 가지 이유로 (Scott Whitlock의 경우 +1, 백업에 대한 마지막 단락 및 mya가 문제를 일으킨다는 점을 참조하십시오.) 그러나 SOA 서비스가 제대로 설계되어있는 것이 중요합니다. DBA가 아닙니다. 궁극적으로 모든 데이터베이스는 “엔터프라이즈 데이터웨어 하우스”에 속합니다.
마지막으로 Scott Whitlock의 마지막 단락, 특히
분리 문제 때문에 테이블을 다른 물리적 데이터베이스로 분리하지는 않습니다.
정말 중요합니다. 이유가 없으면하지 마십시오.
답변
데이터 통합으로 인해 소프트웨어 아키텍처에서 최악의 악몽을 겪어 왔으며, 지금까지 ID DDD-Style Bounded Contexts에서 만난 이러한 유형의 혼란에 대한 최고의 무기를 보았습니다. 어떤 의미에서 “SOA가 올바르게 수행됨”에서 그리 멀지 않은 것입니다.
그러나 데이터 자체가 문제를 공격하는 가장 좋은 방법은 아닙니다. 예상 / 필요한 행동에 중점을두고 중요한 데이터를 가져와야합니다. 우리는 이런 방식으로 중복을 겪게 될 수도 있지만, 이는 거의 항상 데이터 통합 아키텍처와 관련된 시스템 진화에 대한 블록과 비교할 때 일반적으로 문제가되지 않습니다.
간단히 말해서 : 느슨하게 연결된 시스템을 찾고 있다면 데이터를 계속 연결하지 마십시오. “lingua franca”의 역할을하는, 사이에 봉입 된 시스템과 체계적인 통신 채널을 찾으십시오.
답변
데이터베이스 분리 및 데이터베이스 간 데이터 일관성 유지는 전문가 수준의 작업입니다. 현재 시스템이 피하도록 설계된 것은 잘못되기 쉽고 복제본 등의 문제로 끝납니다. 솔직히, 작업 시스템을 가지고 이것을하는 것은 사용자에게 실질적인 가치가없는 새로운 버그를 도입하는 것을 보증합니다.
답변
올바르게 수행하면 비즈니스 관심사를 다른 데이터베이스 (또는 적어도 다른 스키마) 로 분리하는 것이 미덕 입니다.
CQRS 패턴에 대한 Martin Fowler의 설명을 참조하십시오 .
우리의 요구가 더욱 정교 해짐에 따라 우리는 [CRUD 데이터 스토어와 같은 정보 시스템을 처리하는 것]에서 꾸준히 멀어지고 있습니다 … CQRS가 도입 한 변화는 해당 개념 모델을 업데이트 및 디스플레이를 위해 별도의 모델로 분할하는 것입니다 … 상당한 변화의 여지가 있습니다 여기. 메모리 내 모델은 동일한 데이터베이스를 공유 할 수 있으며,이 경우 데이터베이스는 두 모델 간의 통신 역할을합니다. 그러나 이들은 별도 의 데이터베이스를 사용하여 실시간 ReportingDatabase를 통해 쿼리 측 데이터베이스 를 효과적으로 만들 수도 있습니다 . 이 경우 두 모델 또는 데이터베이스간에 통신 메커니즘이 필요합니다.
그리고 NServiceBus 아키텍처 원칙 :
명령 쿼리 분리
이 문제를 피하는 솔루션은 클라이언트 및 서버보다 시스템 수준에서 명령과 쿼리를 분리합니다. 이 솔루션에는 클라이언트와 서버 모두에 걸쳐 두 가지 “서비스”가 있습니다. 하나는 명령을 담당하고 (작성, 업데이트, 삭제), 다른 하나는 쿼리를 담당합니다 (읽기). 이 서비스는 메시지를 통해서만 통신합니다. 하나는 다른 데이터베이스에 액세스 할 수 없습니다.
명령 및 쿼리 책임 분리
대부분의 응용 프로그램은 데이터를 쓰는 것보다 더 자주 데이터를 읽습니다. 이 문장을 바탕으로 읽을 데이터베이스를 더 쉽게 추가 할 수있는 솔루션을 만드는 것이 좋습니다. 읽기 전용 데이터베이스를 설정하면 어떻게 될까요? 더 나은; 데이터베이스를 더 빨리 읽을 수 있도록 데이터베이스를 디자인하면 어떻게 될까요? CQRS 아키텍처에 설명 된 패턴을 기반으로 애플리케이션을 설계하면 데이터를 빠르게 읽을 수있는 솔루션이 제공됩니다.