2010-12-15 30 views
11

Nhóm của tôi đang bắt đầu triển khai ứng dụng greenfield, với yêu cầu cho thuê nhiều bên. Tôi đã thực hiện một số lượng lớn các nghiên cứu về các mô hình cho khả năng mở rộng đơn giản, đặc biệt là trên cơ sở hạ tầng dựa trên đám mây phân tán và CQRS có vẻ là một từ thông dụng (cho đến nay được gọi là "Crack for Architecture Addicts")). Lợi ích và cạm bẫy sang một bên, nó là khá khó khăn để tìm thấy bất cứ ai ngoài Greg Young đã sử dụng ý tưởng này rộng rãi (hoặc ở tất cả) trong các ứng dụng sản xuất và có thể cung cấp hướng dẫn thực tế cho nó.Kiến trúc CQRS đa người thuê nhà

Vì vậy, đây là câu hỏi của tôi: 1. Kiến trúc CQRS có phù hợp với ứng dụng đa đối tượng thuê của bạn hay phù hợp hơn với các ứng dụng doanh nghiệp nội bộ quy mô lớn hơn. 2. Nếu bạn đề nghị rằng nó được sử dụng trong tình huống này, bạn có thể cung cấp một số hướng dẫn về phương pháp tiếp cận - đặc biệt là những điều cần làm ngay từ đầu và những khía cạnh nào cần được phát triển hữu cơ. 3. Nếu bất cứ ai đã cố gắng và thấy nó quá khó hoặc không nhận ra lợi ích, hoặc có những tranh luận mạnh mẽ chống lại nó (và đề nghị gắn bó với CRUD và thiết kế theo tầng), tôi cũng muốn biết về những trải nghiệm đó.

Để tham khảo, ứng dụng sẽ được viết bằng .NET và giao diện người dùng ban đầu sẽ là dựa trên web (ASP.NET MVC), có khả năng được mở rộng cho khách hàng di động và dày. Đồng thời, hoạt động giao dịch và khối lượng dữ liệu được dự kiến ​​sẽ duy trì tương đối thấp trong suốt vòng đời của ứng dụng (so với các ứng dụng tài chính có khối lượng lớn và tương tự). Đối với cơ sở hạ tầng, chúng tôi dự định sử dụng Azure.

+0

(Đặt câu trả lời này không phải là câu trả lời vì nó không thực sự giải quyết các chi tiết cụ thể của câu hỏi của bạn) Nếu bạn chưa có, tôi khuyên bạn nên đọc một bài viết làm rõ CQRS của Udi tại đây: http: // www.udidahan.com/2009/12/09/clarified-cqrs/ và xem video của anh ấy trên đó tại đây: http://skillsmatter.com/podcast/open-source-dot-net/udi-dahan-command-query- trách nhiệm phân biệt/rl-311 –

+2

Cũng đặc biệt cho .NET Azure CQRS kiểm tra http://abdullin.com/ và dự án Lokad http://code.google.com/p/lokad-cqrs/ –

+0

Michael, cảm ơn các bình luận, ý kiến. Tôi đã thực sự đọc qua và theo dõi một lượng thông tin rất lớn về mô hình này, bao gồm cả các tài nguyên này. Những gì có vẻ là thiếu là bất kỳ tiếng nói từ những người đã sử dụng này trong một thời gian, hoặc thậm chí chỉ trong quá trình thực hiện nó ngay bây giờ. Trước khi tôi thực hiện các bước nắm lấy lợi ích lý thuyết, tôi muốn xác thực rằng những thách thức trong thế giới thực đi kèm với chúng không quá lớn. Là một trong những câu nói yêu thích của tôi, "Về lý thuyết, lý thuyết và thực hành đều giống nhau. Trong thực tế, chúng hiếm khi xảy ra." – Mafuba

Trả lời

6

Tôi đã kiểm tra cùng một điểm xuất phát, từ góc độ thăm dò trước khi bắt tay vào dự án thực tế (chúng tôi vẫn đang chờ tài trợ kinh doanh). Trong đó, nghiên cứu và ý kiến ​​của tôi được hình thành từ đó là trục nhiều người thuê của kiến ​​trúc phần lớn là trực giao với việc sử dụng CQRS cho thiết kế nội bộ của một dịch vụ hạt thô.Yêu cầu nhiều bên thuê đặt thêm các hạn chế bao quát xung quanh cách ứng dụng tách biệt các đối tượng thuê khỏi một quan điểm bảo mật, dữ liệu, bản trình bày/cá nhân hóa, triển khai/cấp phép và khả năng mở rộng. CQRS không thực sự làm cho điều này tốt hơn hoặc tệ hơn và theo ý kiến ​​của tôi vẫn có giá trị trong việc giải quyết các thách thức kiến ​​trúc có giá trị cho Dịch vụ. Điều đó nói rằng, không phải tất cả các dịch vụ hợp tác lỏng lẻo để cung cấp ứng dụng cần phải tuân theo mẫu CQRS, với điều kiện là kiến ​​trúc được ghép lỏng lẻo được chọn không cấm sử dụng nó.

2

Tôi không nghĩ nhiều người thuê nhà khó sử dụng CQRS hơn. Bạn có lợi thế khác nhau nếu bạn sử dụng tin nhắn: bạn có thể nhúng nhận dạng người thuê trong các lệnh và sự kiện dưới dạng dữ liệu tiêu đề, chọn một cửa hàng sự kiện dựa trên việc xác định, kết hợp nhiều đối tượng thuê với nhiều trường hợp. Tuy nhiên, hãy tự hỏi liệu tên miền của bạn có hợp tác cao và có chuyên gia tên miền theo ý của bạn ... nếu không bạn kết thúc bằng lệnh/event-cud ;-)

7
  1. Nhiều thời gian thuê sẽ thay đổi một mặt đọc CQRS . Bạn sẽ cần phải lọc chế độ xem và chỉ trả lại dữ liệu có liên quan đến người thuê nhà. Và bạn sẽ phải đối mặt với cùng một vấn đề bằng cách sử dụng bất kỳ kiến ​​trúc nào khác.
  2. Tôi muốn giới thiệu CQRS vì nó sẽ làm cho ứng dụng của bạn dựa trên nhiệm vụ (không phải dựa trên CRUD). Điều đó có nghĩa là bạn sẽ có các lệnh nhận được từ giao diện người dùng và chúng sẽ có ý nghĩa hơn các DTO. Nếu bạn muốn viết cốt lõi của mình với các nguyên tắc DDD thì hãy cố gắng tránh Mô hình miền không ổn định (http://martinfowler.com/bliki/AnemicDomainModel.html). Phương pháp tiếp cận để thực hiện việc này - di chuyển tất cả logic của miền cụ thể đến các đối tượng miền. Xử lý lệnh của bạn nên rất đơn giản (xác thực, tải tổng hợp gốc, dịch đối tượng lệnh để gọi phương thức, nếu không có ngoại lệ nào được ném - áp dụng thay đổi). Thật đáng để xem hồ sơ của Greg (6 giờ rưỡi): http://cqrsinfo.com/video/ Như Michael Shimmins đã nói nếu bạn dự định sử dụng Azure làm nền tảng của bạn - bạn nên xem dự án Lokad.CQRS. Tôi đã sử dụng nó để thực hiện một trong các dự án của chúng tôi.
  3. CQRS sẽ không phù hợp nếu bạn thực sự cần ứng dụng CRUD đơn giản (không phải dựa trên nhiệm vụ). CQRS cần thêm thời gian để hiểu được nguyên tắc của những người mới đến. Ở phía bên kia, nó sẽ cho phép tách các nhiệm vụ dev giữa các lập trình viên miền lõi và các lập trình viên có ít kinh nghiệm hơn -> dto-> ui.
Các vấn đề liên quan