도메인이 풍부한 애플리케이션에서보고 및 대시 보드의 데이터 검색을위한 모범 사례 또는 디자인 패턴

첫째, 이것이 무시 된 질문 / 영역 인 것처럼 말하고 싶습니다.이 질문을 개선 해야하는 경우이 질문을 다른 사람들에게 도움이 될 수있는 훌륭한 질문으로 만드십시오! 나는 시도 할 아이디어뿐만 아니라이 문제를 해결하는 솔루션을 구현 한 사람들의 조언과 도움을 찾고 있습니다.

필자의 경험에는 응용 프로그램의 두 가지 측면이 있습니다. "작업"측면은 주로 도메인 중심이며 사용자는 도메인 모델 (응용 프로그램의 "엔진") 및 사용자가보고하는 측면과 풍부하게 상호 작용하는 곳입니다. 작업 측면에서 발생하는 일을 기반으로 데이터를 가져옵니다.

작업 측면에서 리치 도메인 모델이있는 애플리케이션은 도메인 모델에 비즈니스 로직이 있어야하며 데이터베이스는 주로 지속성을 위해 사용해야합니다. 우려의 분리, 모든 책은 그것에 대해 쓰여졌습니다. 우리는 무엇을 해야할지 압니다.

보고 측은 어떻습니까? 데이터웨어 하우스는 수용 가능합니까, 아니면 데이터베이스에 비즈니스 로직과 데이터 자체를 통합하여 설계가 잘못 되었습니까? 데이터베이스의 데이터를 데이터웨어 하우스 데이터로 집계하려면 비즈니스 논리 및 규칙을 데이터에 적용해야하며 해당 논리 및 규칙은 도메인 모델에서 온 것이 아니라 데이터 집계 프로세스에서 온 것입니다. 그게 잘못이야?

비즈니스 로직이 광범위한 대규모 재무 및 프로젝트 관리 응용 프로그램에서 작업합니다. 이 데이터를보고 할 때 보고서 / 대시 보드에 필요한 정보를 가져 오기 위해 수행해야하는 많은 집계가있을 수 있으며 집계에는 많은 비즈니스 논리가 있습니다. 성능 향상을 위해 집계 된 테이블과 저장 프로 시저로 수행했습니다.

예를 들어, 활성 프로젝트 목록을 표시하려면 보고서 / 대시 보드가 필요하다고 가정합니다 (1 만 개의 프로젝트 상상). 각 프로젝트에는 다음과 같은 일련의 메트릭이 필요합니다.

1. 총 예산
2. 지금까지의 노력
3. 연소율
4. 현재 레코딩 속도의 예산 소진 날짜
5. 기타

이들 각각에는 많은 비즈니스 로직이 포함됩니다. 저는 숫자 나 간단한 논리를 곱하는 것에 대해서만 말하는 것이 아닙니다. 예산을 얻으려면 500 명의 다른 요율로 요율표를 적용해야합니다. 각 직원의 시간 (일부 프로젝트, 다른 사람은 승수가 있음), 비용 및 적절한 마크 업 등을 적용해야합니다. 논리는 광범위합니다. 클라이언트에 적절한 시간 내에이 데이터를 가져 오려면 많은 집계 및 쿼리 조정이 필요했습니다.

도메인을 먼저 실행해야합니까? 성능은 어떻습니까? 직접적인 SQL 쿼리를 사용하더라도 클라이언트가 합리적인 시간에 표시 할 수있을만큼이 데이터를 거의 얻지 못합니다. 이러한 모든 도메인 개체를 재수 화하고 응용 프로그램 계층에서 데이터를 혼합 및 일치시키고 집계하거나 응용 프로그램에서 데이터를 집계하려고 시도하는 경우이 데이터를 클라이언트에 충분히 빨리 가져 오는 것을 상상할 수 없습니다.

이 경우 SQL이 데이터를 잘 처리하는 데 능숙한 것 같습니다. 왜 사용하지 않습니까? 그러나 도메인 모델 외부에 비즈니스 로직이 있습니다. 비즈니스 로직에 대한 모든 변경 사항은 도메인 모델 및보고 집계 체계에서 변경해야합니다.

도메인 기반 설계 및 모범 사례와 관련하여 응용 프로그램의보고 / 대시 보드 부분을 디자인하는 방법에 대해 실제로 손실되었습니다.

MVC는 디자인 풍미 듀어이며 현재 디자인에 사용하고 있기 때문에 MVC 태그를 추가했지만보고 데이터가 이러한 유형의 응용 프로그램에 어떻게 적용되는지 파악할 수 없습니다.

책, 디자인 패턴, Google의 핵심 단어, 기사 등 모든 분야에서 도움을 찾고 있습니다. 이 주제에 관한 정보를 찾을 수 없습니다.

편집 및 다른 예

오늘 나는 또 다른 완벽한 예를 보았습니다. 고객이 고객 영업 팀에 대한 보고서를 원합니다. 그들은 간단한 메트릭처럼 보이는 것을 원합니다.

각 영업 사원의 현재 연간 매출액은 얼마입니까?

그러나 그것은 복잡합니다. 각 영업 사원은 여러 영업 기회에 참여했습니다. 일부는 이기고 일부는하지 않았습니다. 각 영업 기회에는 각 역할과 참여에 따라 판매에 대해 일정 비율의 신용이 할당 된 여러 영업 사원이 있습니다. 이제 모든 영업 사원에 대해 데이터베이스에서이 데이터를 가져 오기 위해 수행해야하는 객체 리 하이드 레이션의 양에 대해 도메인을 통과한다고 상상해보십시오.

모두 가져 오기 SalesPeople->
각각에 대해 가져 오기 SalesOpportunities->
각각에 대해 판매의 백분율을 가져오고 판매 금액
을 계산 한 다음 모든 판매 금액 을 합산 하십시오 SalesOpportunity.

그리고 그것은 하나의 메트릭입니다. 또는 SQL 쿼리를 작성하여 신속하고 효율적으로 수행하고 빠르게 조정할 수 있습니다.

편집 2- CQRS 패턴

CQRS 패턴 에 대해 읽었 으며 흥미롭게도 Martin Fowler조차도 테스트되지 않았다고 말합니다. 과거에이 문제가 어떻게 해결 되었습니까? 이것은 어느 시점에서나 모든 사람이 직면해야합니다. 성공한 실적을 가진 확립 된 또는 잘 착용 된 접근법은 무엇입니까?

편집 3-보고 시스템 / 도구

이와 관련하여 고려해야 할 또 다른 사항은보고 도구입니다. Reporting Services / Crystal 보고서, Analysis Services 및 Cognoscenti 등은 모두 SQL / 데이터베이스의 데이터를 기대합니다. 나중에 귀하의 데이터가 귀하의 비즈니스를 통해 올 것 같지는 않습니다. 그럼에도 불구하고 그들과 같은 사람들은 많은 대규모 시스템에서보고의 중요한 부분입니다. 이러한 시스템에 대한 데이터 소스 및 보고서 자체에 비즈니스 로직이있는 경우 이들에 대한 데이터는 어떻게 올바르게 처리됩니까?

이것은 매우 사소한 답변이지만 문제의 핵심을 바로 잡는 것입니다.

DDD와 관련하여보고를 경계 컨텍스트 (Bounded Context)라고 생각할 수 있습니다. 따라서 "THE"도메인 모델을 생각하기보다는 하나 이상의 모델을 갖는 것이 좋다고 생각해야합니다. 그렇습니다. 트랜잭션 도메인에 트랜잭션 비즈니스 로직이있는 것처럼보고 도메인에보고 비즈니스 로직이 있으면 괜찮습니다.

응용 프로그램 코드에서 SQL 저장 프로 시저 대 도메인 모델의 문제에 관해서는 트랜잭션 시스템과 동일한 장단점이보고 시스템에 적용됩니다.

질문에 현상금을 추가 한 것을 보았으므로 질문을 다시 읽고 이에 대한 특정 리소스를 요구한다는 것을 알았으므로 문제에 대한 다른 스택 오버플로 질문을 살펴 보는 것으로 시작하겠다고 생각했습니다. 나는 이것을 https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting 발견했습니다.

그 중 요점은 DDD와 일치하는 CQRS를 시스템의 패턴으로 사용하고보고를 수행하는 방법으로 쿼리 측 책임에 의존하는 것이지만 이것이 유용한 답변인지는 확실하지 않습니다. 너의 경우.

나는 또한 발견이 http://www.martinfowler.com/bliki/ReportingDatabase.html , 내가 여기에서 링크 발견하는 : http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

다음은이 문제에 ACM에서 흥미로운 기사입니다 : http://dl.acm.org/citation.cfm?id=2064685는 하지만 실제로 (아닌 ACM 회원 :()을 읽을 수 있도록이 페이 월 뒤에.

비슷한 질문에 대한 답변이 여기에 있습니다 : https : //.com/questions/3380431/cqrs-ddd-synching-reporting-database

그리고 이것은 하나입니다 : http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

도움이 되었기를 바랍니다!

귀하의 질문에 대한 나의 이해는 이것입니다 : 일상 업무 신청

보기 >> 컨트롤러 >> 모델 (BL) >> 데이터베이스 (데이터)

보고 목적 신청

보기 >> 컨트롤러 >> 모델 >> 데이터베이스 (데이터 + BL)

따라서 ' 작업 응용 프로그램 '에 대한 BL 을 변경하면 ' 보고 'BL도 변경됩니다 . 그게 진짜 문제 야? 글쎄, 두 번 변경해도 괜찮습니다. 어쨌든 고통이 필요합니다. 그 이유는 두 BL이 각각의 관심사에 의해 분리되어 있기 때문입니다. 하나는 데이터를 가져 오기위한 것이고 다른 하나는 데이터를 집계하기위한 것입니다. 또한 원래 BL과 집계 BL은 다른 기술 또는 언어 ( C # / java 및 SQL proc )로 작성됩니다. 탈출구가 없습니다.

구체적으로보고와 관련이없는 다른 예를 보자. 회사 XXX가 해석을 위해 모든 사용자의 메일을 추적하고 해당 정보를 마케팅 회사에 판매한다고 가정하십시오. 이제는 해석 용 BL 하나와 마케팅 회 사용 데이터 집계 용 BL 하나를 갖게됩니다. BL에 대한 우려는 서로 다릅니다. 내일 자신의 BL이 쿠바에서 오는 메일을 무시하도록 변경되면 비즈니스 로직이 양쪽에서 변경됩니다.

리포팅은 느슨하게 말할 수있는 제한된 컨텍스트 또는 하위 도메인입니다. 비즈니스 인텔리전스를 얻기 위해 데이터를 수집 / 집계 및 처리해야하는 비즈니스 요구를 해결합니다.

이 하위 도메인을 구현하는 방법은 (가장) 아키텍처 상 올바른 방법과 인프라에서 허용하는 것 사이의 균형 일 것입니다. 나는 앞면에서 시작하고 후자를 향해 필요한만큼만 움직입니다.

아마도 이것을 해결하려는 두 가지 주요 문제로 나눌 수 있습니다.

1. 데이터 수집 또는웨어 하우징. 이것은 일부 데이터 소스를 처리하고 다른 데이터 소스에 저장되는 방식으로 정보를 결합해야합니다.

2. 비즈니스 인텔리전스를 제공하기 위해 집계 된 데이터 소스를 쿼리합니다.

이러한 문제는 특정 데이터베이스 나 스토리지 엔진을 참조하지 않습니다. 도메인 계층은 다양한 스토리지 어댑터에 의해 인프라 계층에 구현 된 인터페이스 만 처리해야합니다.

다양한 작업자 또는 예정된 작업 실행이있을 수 있으며 몇 개의 움직이는 부분으로 나뉩니다.

• 문의해야 할 것
• 집계 할 것
• 저장할 것

CQRS의 일부가 빛을 발할 수 있기를 바랍니다.

보고 측면에서는 쿼리 만 수행하면되지만 데이터베이스에 직접 연결하면 안됩니다. 여기에서 인터페이스와 도메인 계층을 살펴보십시오. 이것은 기본 작업과 동일한 문제 영역은 아니지만 여기에 준수하려는 논리가 여전히 있어야합니다.

데이터베이스에 직접 들어가 자마자 더 많이 의존하게되며 결국 원래 응용 프로그램의 데이터 요구를 방해 할 수 있습니다.

또한 적어도 저에게는 쿼리 또는 저장 프로 시저보다는 테스트 작성 및 코드 개발을 선호합니다. 또한 절대적으로 필요할 때까지 특정 도구에 자신을 고정시키지 않는 것이 좋습니다.

인터넷을 포함한 광역 네트워크를 통해 대량의 정보를 검색하는 것은 응답 대기 시간, 데이터 서비스 리소스에 대한 직접 메모리 액세스 부족 및 내결함성으로 인해 발생하는 문제로 인해 문제가됩니다.

이 질문은 많은 양의 데이터를 반환하는 쿼리의 결과 처리 문제를 해결하기위한 디자인 패턴을 설명합니다. 일반적으로 이러한 쿼리는 하나 이상의 중간 계층이있는 광역 네트워크 (또는 인터넷)에서 원격 서버에있는 관계형 데이터베이스에 대한 클라이언트 프로세스에 의해 수행됩니다.

이 솔루션에는 데이터 세트를 순회하고 클라이언트에 적절한 추상화 수준을 제공하고 데이터 하위 세트의 이중 버퍼링, 다중 스레드 데이터 검색 및 쿼리 슬라이싱을위한 반복기 사용을 포함하여 데이터 검색 전략의 조합을 구현합니다.

운영 / 트랜잭션 데이터 저장소를보고와 분리하는 것이 일반적입니다. 후자는 법적 이유로 데이터를 유지해야하는 요구 사항이있을 수 있습니다 (예 : 재무 감사를 위해 7 년 동안의 재무 데이터). 귀하는 거래 데이터 저장소에 모든 것을 원하지 않습니다.

따라서 트랜잭션 데이터를 시간 단위 (주별, 월별, 분기 별, 매년)별로 분할하고 오래된 파티션을 ETL을 통해보고 / 기록 데이터 저장소로 옮길 수 있습니다. 스타 스키마 및 차원이있는 데이터웨어 하우스 일 수도 있고 아닐 수도 있습니다. 데이터웨어 하우징보고 도구를 사용하여 임시 쿼리 및 롤업 및 배치 작업을 수행하여 정기적 인 보고서를 생성합니다.

거래 데이터 저장소에 대한보고는 권장하지 않습니다.

누르기를 선호하는 경우 더 많은 생각이 있습니다.

1. "최고"는 주관적이고 작동합니다.
2. 직접 작성하지 않고보고 제품을 구매합니다.
3. 관계형 데이터베이스를 사용하는 경우 SQL이 유일한 게임입니다.
4. 저장 프로시 저는 작성 능력이 있는지 여부에 따라 다릅니다.

집에서 사용하는 프로젝트 관리 소프트웨어? 내가 빌드하기 전에 살 것이다. Rally 및 Microsoft Project와 같은 것.

먼저, 업무 측면이라고하는 일부 용어를 트랜잭션 (Transactional)이라고하며보고 측면은 분석 (Analytics)입니다.

당신은 이미 CQRS에 대해 언급했습니다. CQRS는 훌륭한 접근 방식이지만 실제로 적용되는 문서화는 거의 없습니다.

많은 테스트를 거친 것은 분석 처리 엔진으로 트랜잭션 처리를 보완하는 것입니다. 이를 데이터웨어 하우징 또는 데이터 큐브라고도합니다. 분석과 관련하여 가장 큰 문제는 실시간으로 트랜잭션 데이터에 대해 쿼리를 실행하는 것이 실제로 비효율적이라는 것입니다. 실제로 읽기 또는 쓰기를 위해 데이터베이스를 최적화하는 것만 가능하기 때문입니다. 트랜잭션의 경우 처리 / 작업이 지연되는 것을 피하기 위해 높은 쓰기 속도를 원합니다. 보고를 위해서는 빠른 읽기 속도가 필요하므로 의사 결정을 내릴 수 있습니다.

이러한 문제를 설명하는 방법은 무엇입니까? 이해하는 가장 간단한 방법은보고를 위해 병합 된 스키마와 ETL (추출 변환로드)을 사용하여 정규화 된 트랜잭션 스키마에서 비정규 화 된 분석 스키마로 데이터를 셔틀하는 것입니다. ETL은 에이전트를 통해 정기적으로 실행되며 분석 테이블을 미리로드하여보고 엔진에서 빠르게 읽을 수 있습니다.

Ralph Kimball 의 Data Warehouse Toolkit 은 데이터웨어 하우징에 대한 정보를 제공 합니다. 접근에 대한 더 많은 손길이 필요합니다. SQL Server 평가판을 다운로드하고 첫 번째 책에 대한 일반적인 내용을 다루지 만 SQL Server를 사용하여 개념을 적용하는 방법을 보여주는 Microsoft Data Warehouse 툴킷 을 선택하십시오 .

해당 페이지에서 ETL, Star Schema Design, BI, Dashboards 및 기타 주제에 대한 자세한 정보를 제공하는 여러 링크 된 책이 있습니다.

현재 위치에서 원하는 위치로 이동하는 가장 빠른 방법은 BI 전문가를 고용하여 필요한 것을 구현하는 동안 섀도 잉하는 것입니다.

보고 측은 어떻습니까? 데이터웨어 하우스는 수용 가능합니까, 아니면 데이터베이스에 비즈니스 로직과 데이터 자체를 통합하여 설계가 잘못 되었습니까?

나는 당신이 비즈니스 로직에 대해 이야기하고 있다고 생각하지 않습니다. 이것이 더보고 논리입니다. 이 화면의 정보로 사용자는 무엇을합니까? 단순히 상태 업데이트를위한 것입니까? 도메인 모델은 거래 운영을 모델링하는 데 사용되며보고는 다른 관심사입니다. 보고 시나리오에는 SQL Server에서 데이터를 가져 오거나 데이터웨어 하우스에 넣는 것이 좋습니다.

도메인 모델은 프로젝트 멤버와 같은 도메인의 변형을 강제로 실행하여 동일한 프로젝트에 동시에 예약 할 수 없거나 일주일에 x 시간 만 예약 할 수 있습니다. 또는이 프로젝트가 완료 등으로 예약 할 수 없습니다. 도메인 모델의 상태 (데이터)를 별도로보고하기 위해 복사 할 수 있습니다.

쿼리 성능을 향상시키기 위해 구체화 된보기를 사용할 수 있습니다. 모델에 대해 작업이 커밋 된 경우 (예 :이 사람의 4 시간 예약 x 시간 계획) 이벤트가 성공하면보고 데이터베이스에 저장하고 보고서에 필요한 계산을 수행 할 수 있습니다. 그러면 쿼리하는 것이 매우 빠릅니다.

트랜잭션과보고 컨텍스트를 별도로 유지하십시오. 관계형 데이터베이스는 도메인 모델을보고하지 않았습니다.

편집하다

주제 http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html 에 유용한 블로그 게시물

4 년 후, 나는이 질문을 다시 찾았습니다.

응용 프로그램과 특정 요구 사항에 따라 도메인 / 트랜잭션 데이터베이스와보고는 별도의 "시스템"또는 "엔진"이거나 하나의 시스템에서 서비스 할 수 있습니다. 그러나 논리적으로 분리되어야합니다. 즉, 데이터를 검색하고 UI에 제공하는 다른 방법을 사용합니다.

나는 그것들이 물리적으로 분리되는 것을 선호하지만 (논리적으로 분리되는 것 외에도) 많은 시간을 함께 (물리적으로) 시작한 다음 응용 프로그램이 성숙함에 따라 분리합니다.

어느 쪽이든, 다시 논리적으로 달라야합니다. 보고 시스템에서 비즈니스 로직을 복제해도됩니다. 중요한 것은보고 시스템이 도메인 시스템과 동일한 답변을 얻는다는 것입니다. 그러나 다른 방법을 통해 도달 할 가능성이 있습니다. 예를 들어 도메인 시스템에는 절차 코드로 구현 된 매우 엄격한 비즈니스 규칙이 많이있을 것입니다. 보고 시스템은 데이터를 읽을 때 동일한 규칙을 구현할 수 있지만 SET 기반 코드 (예 : SQL)를 통해 그렇게 할 수 있습니다.

다음은 애플리케이션 아키텍처가 진화함에 따라 현실적으로 어떤 모습 일지 보여줍니다.

수준 1-논리적으로 분리 된 도메인 및보고 시스템이지만 여전히 동일한 코드베이스 및 데이터베이스

수준 2-논리적으로 분리 된 도메인 및보고 시스템이지만 동기화를 통해 데이터베이스를 분리합니다.

수준 3-논리적 및 물리적으로 분리 된 도메인 및보고 시스템과 동기화를 통해 데이터베이스를 분리합니다.

주요 아이디어는보고와 도메인의 요구 사항이 크게 다르다는 것입니다. 다른 데이터 프로파일 (읽기 대 쓰기 및 업데이트 빈도), 다른 성능 요구 사항 등 서로 다르게 구현해야하며 비즈니스 논리를 일부 복제해야합니다.

도메인과보고 시스템의 비즈니스 로직을 서로 최신 상태로 유지하는 방법을 고안하는 것은 비즈니스에 달려 있습니다.

활성 프로젝트 목록을 표시하려면 보고서 / 대시 보드가 필요합니다

각 프로젝트의 상태는 데이터베이스에 정적 으로 계산 되고 형식이 잘 지정된 정보로 저장 되어야하며 시뮬레이션 은 클라이언트에서 WebApp으로 처리해야합니다.

현재 레코딩 속도의 예산 소진 날짜

이러한 유형의 프로젝션은 요청시 실행해서는 안됩니다. 리소스, 요율, 작업, 마일스톤 등의 계산 수행과 같이 요청에 따라이 정보를 관리 하면 향후 통화에 이러한 결과를 재사용하지 않고도 계산 계층 을 광범위하게 사용할 수 있습니다 .

분산 환경 ( 프라이빗 또는 퍼블릭 클라우드 )을 상상하면 계산 계층, 데이터베이스 사용률이 낮고 전체 캐시 부족으로 막대한 비용이 발생합니다.

도메인을 먼저 실행해야합니까? 성능은 어떻습니까?

소프트웨어 설계에는 판독이 아닌 "데이터 입력"중에 필요한 결과를 얻는 데 필요한 계산을 정규화 할 수있는 기능이 포함되어야합니다. 이 접근 방식은 컴퓨팅 리소스 사용을 크게 줄이고 무엇보다도 고객이 "읽기 전용"으로 간주 할 수있는 테이블을 만듭니다. 이것은 캐싱 메커니즘을 견고하고 단순하게 만드는 첫 번째 단계입니다.

따라서 소프트웨어 아키텍처를 완료하기 전에 먼저 검색을 수행하면 분산 캐시 시스템 이 될 수 있습니다 .

(요청 : 집계)! = 1 : 1

따라서 (첫 번째와 두 번째 예 모두) 고려 사항은 클라이언트 요청 당 집계를 줄이기 위해 데이터를 정규화하는 것이 적절한시기를 이해하는 것입니다. 하나의 목표가 지속 가능한 시스템을 얻는다면 1 : 1 (요청 : 집계)이 될 수 없습니다.

고객에게 계산을 배포

또 다른 질문은 소프트웨어 설계를 마치기 전에 얼마나 많은 정규화가 클라이언트 브라우저를 위임하고 싶습니까?

이름이 MV * 였으며 오늘날 유행하는 것은 사실입니다.이 외에도 그 목적 중 하나는 많은 복잡한 응용 프로그램의 현재로 간주 될 수있는 WebApp (단일 페이지 응용 프로그램)을 만드는 것입니다. 우리는 클라우드 공급자에게 지불하며, 이들은 클라이언트에서 실행됩니다).

그러므로 나의 결론은 다음과 같다.

1. 데이터 표현을 수행하는 데 실제로 얼마나 많은 작업이 필요한지 이해

2. 백그라운드 에서 수행 할 수있는 작업 수를 분석 한 다음 정규화 후 캐시 시스템을 통해 배포합니다.

3. 클라이언트에서 실행할 수있는 작업 수를 이해하고, 프로젝트 구성을 가져 와서 웹 애플리케이션의보기에서 실행하여 백엔드에서 수행되는 계산을 줄입니다.

쿼리에는 캐시를 사용하고 캐싱에는 도메인을 사용하십시오.

stackoverflow에는 "최고 사용자"라는 기능이 있습니다. "최고 사용자 페이지"에서 "커뮤니티 위키 이외의 질문과 답변 만이 총계에 포함 됩니다 (매일 업데이트 됨 )"라는 문구가 있습니다 . 이는 데이터가 캐시되었음을 나타냅니다.

그런데 왜?

성능 문제 일 수 있습니다. 도메인 논리 유출과 동일한 우려가있을 수 있습니다 (이 경우 "비공개 위키 질문과 답변 만 합계에 포함됨").

어떻게?

나는 그들이 어떻게했는지 알지 못하므로 여기에 추측이 있습니다 :)

먼저, 대상 질문 / 답을 찾아야합니다. 예약 작업이 작동 할 수 있으며 모든 잠재적 대상을 가져옵니다.

둘째, 하나의 질문 / 답변 만 봅시다. 커뮤니티 위키가 아닌 것입니까? 30 일 이내에 있습니까? 도메인 모델로 대답하기는 매우 쉽습니다. 투표를 세고 만족하면 캐시하십시오.

이제 캐시가 생겼으며 도메인 파생의 결과물입니다. 적용 할 간단한 기준 만 있기 때문에 쿼리가 빠르고 쉽습니다.

결과가 "실시간"이어야한다면 어떻게해야합니까?

이벤트가 도움이 될 수 있습니다. 스케줄링 작업으로 캐싱을 트리거하는 대신 프로세스를 여러 하위 프로세스로 분할 할 수 있습니다. 예를 들어 누군가 누군가 hippoom의 답변에 투표하면 hippoom의 최고 사용자 캐시 업데이트를 트리거하는 이벤트를 게시합니다. 이 경우, 우리는 빠른 작업을 자주 보게 될 것입니다.

CQRS가 필요합니까?

예약 작업 접근 방식이나 이벤트 접근 방식이 아닙니다. 그러나 cqrs는 이점이 있습니다. 캐시는 일반적으로 고도로 표시 지향적입니다. 처음에 일부 항목이 필요하지 않은 경우 계산 및 캐시하지 않을 수 있습니다. 이벤트 소싱 기능이있는 CQRS는 이벤트를 재생하여 기록 데이터의 캐시를 재구성하는 데 도움이됩니다.

관련 질문 :
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use 리치 도메인과 대규모 작업 / 19416703

그것이 도움이되기를 바랍니다 :)

면책 조항 :
도메인 모델이있는 응용 프로그램에는 경험이 없습니다.
나는 모든 개념을 이해하고 있으며 이미이 개념을 작업중인 응용 프로그램 (도메인이 풍부하지만 OO, 실제 도메인 모델 등이 없음) 에 적용하는 방법에 대해 오랫동안 생각해 왔습니다 .
이 질문은 제가 직면 한 주요 문제 중 하나입니다. 이 문제를 해결하는 방법에 대한 아이디어가 있지만 방금 말했듯이 ... 내가 생각한 아이디어 일뿐입니다.
실제 프로젝트에서는 아직 구현하지 않았지만 작동하지 않는 이유는 알 수 없습니다.

이제 그것을 분명히 했으므로 여기에 내가 생각해 낸 내용이 있습니다. 첫 번째 예제 (프로젝트 메트릭) 를 사용하여 설명 하겠습니다 .

누군가 프로젝트를 편집하면 어쨌든 도메인 모델을 통해 프로젝트를로드하고 저장하는 것입니다.
지금이 순간, 당신은 이 모든 모든 통계를 계산하기 위해로드 정보 (총 예산, 날짜 등의 노력) 이 프로젝트를.

도메인 모델에서이를 계산하고 나머지 도메인 모델과 함께 데이터베이스에 저장할 수 있습니다.
소위 Project도메인 모델 클래스는 같은 몇 가지 특성 것 TotalBudget, EffortToDate등, 또한이 도메인 모델이 저장되는 데이터베이스 테이블에서 그 이름을 가진 열이있을 것 같은 테이블에 (또는 별도의 테이블 ... 아무튼에서 상관 없습니다) .

물론이 작업을 시작할 때 모든 기존 프로젝트의 값을 계산하려면 한 번만 실행해야합니다. 그러나 그 후에는 프로젝트가 도메인 모델을 통해 편집 될 때마다 데이터가 현재 계산 된 값으로 자동 업데이트됩니다.

따라서 모든 종류의 보고서가 필요할 때마다 필요한 모든 데이터가 이미 사전 계산되어 있으며 다음과 같이 할 수 있습니다.

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

도메인 모델이 저장된 테이블에서 직접 데이터를 가져 오든, 아니면 데이터를 두 번째 데이터베이스, 데이터웨어 하우스 또는 기타로 추출하는 경우에는 중요하지 않습니다.

1. 보고 저장소가 실제 데이터 저장소와 다른 경우 "도메인 모델 테이블"에서 데이터를 복사하면됩니다.
2. 실제 데이터 저장소를 직접 쿼리하는 경우 데이터가 이미 존재하므로 아무 것도 계산할 필요가 없습니다.

두 경우 모두 계산을위한 비즈니스 로직은 정확히 한 곳에 있습니다 (도메인 모델).
다른 곳에서는 필요하지 않으므로 복제 할 필요가 없습니다.