Đầu tiên, tôi muốn nói đây có vẻ là một câu hỏi / lĩnh vực bị bỏ quên, vì vậy nếu câu hỏi này cần cải thiện, hãy giúp tôi biến nó thành một câu hỏi tuyệt vời có thể mang lại lợi ích cho người khác! Tôi đang tìm kiếm lời khuyên và sự giúp đỡ từ những người đã thực hiện các giải pháp giải quyết vấn đề này, không chỉ là ý tưởng để thử.
Theo kinh nghiệm của tôi, có hai mặt của một ứng dụng - phía "tác vụ", phần lớn được điều khiển theo miền và là nơi người dùng tương tác phong phú với mô hình miền ("công cụ" của ứng dụng) và phía báo cáo, nơi người dùng lấy dữ liệu dựa trên những gì xảy ra ở phía nhiệm vụ.
Về mặt nhiệm vụ, rõ ràng một ứng dụng có mô hình miền phong phú nên có logic nghiệp vụ trong mô hình miền và cơ sở dữ liệu nên được sử dụng chủ yếu để duy trì. Tách biệt các mối quan tâm, mỗi cuốn sách được viết về nó, chúng tôi biết phải làm gì, tuyệt vời.
Còn phía báo cáo thì sao? Các kho dữ liệu có được chấp nhận hay chúng có thiết kế xấu vì chúng kết hợp logic kinh doanh trong cơ sở dữ liệu và chính dữ liệu đó? Để tổng hợp dữ liệu từ cơ sở dữ liệu thành dữ liệu kho dữ liệu, bạn phải áp dụng logic và quy tắc kinh doanh cho dữ liệu và logic và quy tắc đó không xuất phát từ mô hình miền của bạn, nó đến từ các quy trình tổng hợp dữ liệu của bạn. Là sai đó?
Tôi làm việc trên các ứng dụng quản lý dự án và tài chính lớn, nơi logic kinh doanh rộng khắp. Khi báo cáo về dữ liệu này, tôi thường sẽ có RẤT NHIỀU tập hợp để thực hiện để lấy thông tin cần thiết cho báo cáo / bảng điều khiển và các tập hợp có rất nhiều logic nghiệp vụ trong đó. Để thực hiện, tôi đã thực hiện nó với các bảng tổng hợp cao và các thủ tục được lưu trữ.
Ví dụ: giả sử cần có báo cáo / bảng điều khiển để hiển thị danh sách các dự án đang hoạt động (hãy tưởng tượng 10.000 dự án). Mỗi dự án sẽ cần một bộ số liệu được hiển thị cùng với nó, ví dụ:
- Tổng ngân sách
- nỗ lực cho đến nay
- tỷ lệ bỏng
- ngày cạn kiệt ngân sách ở mức hiện tại
- Vân vân.
Mỗi trong số này liên quan đến rất nhiều logic kinh doanh. Và tôi không chỉ nói về việc nhân số hoặc một số logic đơn giản. Tôi đang nói về để có được ngân sách, bạn phải áp dụng một bảng tỷ lệ với 500 mức giá khác nhau, một mức cho mỗi thời gian của nhân viên (trên một số dự án, các dự án khác có số nhân), áp dụng chi phí và bất kỳ đánh dấu thích hợp nào, v.v. logic là rộng rãi. Phải mất rất nhiều điều chỉnh tổng hợp và truy vấn để có được dữ liệu này trong một khoảng thời gian hợp lý cho khách hàng.
Điều này có nên được chạy qua tên miền đầu tiên? Hiệu suất thì sao? Ngay cả với các truy vấn SQL thẳng, tôi hầu như không nhận được dữ liệu này đủ nhanh để khách hàng hiển thị trong một khoảng thời gian hợp lý. Tôi không thể tưởng tượng việc cố gắng đưa dữ liệu này đến máy khách đủ nhanh nếu tôi đang bù nước cho tất cả các đối tượng miền này, trộn lẫn và kết hợp và tổng hợp dữ liệu của chúng trong lớp ứng dụng hoặc cố gắng tổng hợp dữ liệu trong ứng dụng.
Có vẻ như trong các trường hợp này, SQL rất giỏi trong việc bẻ khóa dữ liệu và tại sao không sử dụng nó? Nhưng sau đó bạn có logic kinh doanh bên ngoài mô hình miền của bạn. Mọi thay đổi đối với logic nghiệp vụ sẽ phải được thay đổi trong mô hình miền và các sơ đồ tổng hợp báo cáo của bạn.
Tôi thực sự không biết cách thiết kế phần báo cáo / bảng điều khiển của bất kỳ ứng dụng nào liên quan đến thiết kế hướng tên miền và các thông lệ tốt.
Tôi đã thêm thẻ MVC vì MVC là hương vị thiết kế và tôi đang sử dụng nó trong thiết kế hiện tại của mình, nhưng không thể hiểu làm thế nào dữ liệu báo cáo phù hợp với loại ứng dụng này.
Tôi đang tìm kiếm bất kỳ trợ giúp trong lĩnh vực này - sách, mẫu thiết kế, từ khóa cho google, bài viết, bất cứ điều gì. Tôi không thể tìm thấy bất kỳ thông tin về chủ đề này.
EDIT VÀ VÍ DỤ KHÁC
Một ví dụ hoàn hảo khác mà tôi đã chạy qua ngày hôm nay. Khách hàng muốn báo cáo cho Nhóm bán hàng của khách hàng. Họ muốn những gì có vẻ như là một số liệu đơn giản:
Đối với mỗi nhân viên bán hàng, doanh số hàng năm của họ là gì?
Nhưng điều đó thật phức tạp. Mỗi người bán hàng tham gia vào nhiều cơ hội bán hàng. Một số họ đã thắng, một số thì không. Trong mỗi cơ hội bán hàng, có nhiều nhân viên bán hàng, mỗi người được phân bổ một tỷ lệ tín dụng cho việc bán hàng theo vai trò và sự tham gia của họ. Vì vậy, bây giờ hãy tưởng tượng đi qua miền cho việc này ... lượng bù nước đối tượng bạn sẽ phải làm để lấy dữ liệu này từ cơ sở dữ liệu cho mỗi nhân viên Bán hàng:
Nhận tất cả
SalesPeople->
Đối với mỗi người nhận đượcSalesOpportunities->
Đối với mỗi người, hãy lấy phần trăm doanh số của họ và tính số tiền Bán hàng của họ
sau đó Cộng tất cảSalesOpportunitysố tiền Bán hàng của họ .
Và đó là MỘT số liệu. Hoặc bạn có thể viết một truy vấn SQL có thể thực hiện nhanh chóng và hiệu quả và điều chỉnh nó nhanh.
EDIT 2 - Mẫu CQRS
Tôi đã đọc về Mẫu CQRS và, trong khi hấp dẫn, ngay cả Martin Fowler cũng nói rằng nó chưa được thử nghiệm. Vì vậy, làm thế nào có vấn đề này đã được giải quyết trong quá khứ. Điều này phải được mọi người đối mặt vào lúc này hay lúc khác. Một cách tiếp cận được thiết lập hoặc mòn với một hồ sơ thành công là gì?
Chỉnh sửa 3 - Hệ thống / Công cụ báo cáo
Một điều khác cần xem xét trong bối cảnh này là các công cụ báo cáo. Dịch vụ báo cáo / Báo cáo pha lê, Dịch vụ phân tích và Cognoscenti, v.v ... tất cả đều mong đợi dữ liệu từ SQL / cơ sở dữ liệu. Tôi nghi ngờ dữ liệu của bạn sẽ thông qua doanh nghiệp của bạn sau này cho những điều này. Tuy nhiên, họ và những người khác giống như họ là một phần quan trọng của báo cáo trong rất nhiều hệ thống lớn. Làm thế nào là dữ liệu cho những dữ liệu này được xử lý đúng cách khi có ngay cả logic kinh doanh trong nguồn dữ liệu cho các hệ thống này cũng như có thể trong chính các báo cáo?
