CQRS LÀ GÌ

     

CQRS ?

Đây là 1 trong pattern được viết tắt do Command Query Responsibility Segregation, dịch nôm na là phân tách bóc vai trò Command (tượng trưng cho câu hỏi ghi dữ liệu) với Query (tượng trưng cho việc đọc dữ liệu). CQRS được biểu lộ lần đầu bởi tác giả Greg Young.

Bạn đang xem: Cqrs là gì

CQRS vs CQS tương tự như với CQRS là pattern CQS (Command Query Separation) được reviews bởi Bertrand Meyer trong cuốn Object Oriented Software Construction. CQRS được xem như là một trong mở rộng lớn của CQS. Rất có thể coi CQS thể hiện ở mức class hoặc component level còn CQRS miêu tả ở bounded context level.

CQS yêu cầu bóc tách biệt các method cho vấn đề query hoặc writing cho 1 model: Query ko được chuyển đổi state, trong lúc Command được biến hóa state mà lại không trả về 1 quý hiếm nào.

CQRS cũng có ý tưởng tựa như nhưng rõ ràng hơn. Một Query request sẽ tách biệt cùng với Command request. Một Query trả về data cơ mà không đổi khác state của system, Command biến hóa system nhưng mà không trả về data. Sự khác hoàn toàn cơ phiên bản là trong quy mô CQRS, tất cả các object đã được phân thành 2 object: 1 object đến Query và 1 object cho Command.

ON THE WAY khổng lồ CQRS

Để hiểu rõ hơn về phong cách xây dựng CQRS, ta sẽ ban đầu từ kiến trúc truyền thống cuội nguồn (n-tier (layer) architecture). Trong kiến trúc N-Tier layer, việc đổi khác dữ liệu thường áp dụng CRUD (create, read, update và delete)

*

Nếu họ muốn sửa phong cách xây dựng này theo nguyên lý CQS thì chúng ta chỉ dễ dàng và đơn giản là bóc khối Business logic thành Commands và Queries:

*

Nếu bạn đang cần phân tách bóc rõ 2 side Query và Command trên khối hệ thống với mã nguồn sẽ dựng sẵn thì cách này chắc hẳn là bước trở ngại nhất. Command: tiến hành command là phương pháp duy độc nhất để chuyển đổi state của hệ thống. Command phụ trách cho tất cả các biến hóa trong hệ thống. Nếu không tồn tại Command nào thực thi, state của khối hệ thống sẽ giữ nguyên. Thực thi Command không nên trả về ngẫu nhiên giá trị gì. (Nên thực thi tương tự kiểu void function) Query: là triển khai việc đọc dữ liệu. Nó gọi state của system và hoàn toàn có thể filter, aggregate và đổi khác form data theo định dạng mong muốn. Query bắt buộc trả về kết quả.

Tiếp tục trở lại phong cách thiết kế ở trên, bạn có thể chuyển đổi model trở thành domain name Model. Cùng với Model, bạn hiểu được tập hợp những data container trong những lúc Domain mã sản phẩm đóng gói thành những nghiệp vụ phức tạp. Cùng với việc chuyển đổi này, bạn cũng có thể dễ hiểu Command phụ trách cho việc biến hóa state trong số những nghiệp vụ phức tạp và nên đặt tại Domain Model. Ngoại trừ ra, bạn có thể thấy rõ rằng domain Model phù hợp cho việc ghi dữ liệu trong những khi nó không duy nhất thiết cần cho vấn đề đọc dữ liệu.

Xem thêm: Sẽ Mất Bao Lâu Để Cập Nhật Ios Mất Bao Nhiêu Thời Gian, Bị Treo Máy Thì Làm Thế Nào

*

Tiếp theo, bạn cũng có thể ánh xạ áp dụng READ model với ORM (Object Relational Mapping) và thực hiện nó để build những câu tróc nã vấn. Thực hiện ORM sẽ có lợi để đơn giản mô hình này.

*

Hiện tại, vấn đề là bọn họ là vẫn có READ và WRITE model bóc biệt chỉ làm việc mức lô ghích level và chúng vẫn dùng thông thường database. Điều đó tức là READ model đơn giản dễ dàng chỉ là mức virtualized như DB Views, giỏi hơn có thể là Materialized Views. Chiến thuật này là OK nếu hệ thống của bọn họ không ảnh hưởng nhiều bởi vấn đề performance.

Tiếp theo, bạn cũng có thể tách biệt hoàn toàn Data Model. READ model sẽ được update vì các event khi WRITE Domain model thực thi. Đến cách này, bạn có thể gọi thiết kế này là CQRS

*

CQRS != event Sourcing

Cần minh bạch giữa CQRS và sự kiện Sourcing. Event Sourcing là 1 khái niệm thường được sử dụng với CQRS và nó rất có thể được khẳng định là 1 phần của CQRS. Ý tưởng của sự kiện Sourcing rất 1-1 giản: Domain sẽ tạo ra các events (đó là các biến hóa của hệ thống). Nếu chúng ta lấy toàn bộ các event từ lúc bắt đầu hệ thống và thực hiện lại trên trạng thái ban đầu thì chúng ta sẽ có trạng thái hiện tại. Ví dụ thực tế là khi chúng ta mở thông tin tài khoản tại ngân hàng, những giao dịch (transaction) là các event. Khi mở tài khoản ban sơ thì tài khoản là 0 sau khi họ thực hiện toàn thể các event (transaction) thì chúng ta có thông tin tài khoản hiện tại.

*

Trong khi event Sourcing là cách thức hiệu quả để lưu các trạng thái của hệ thống thì nó cũng không nhất thiết gồm trong mô hình CQRS. Trong quy mô CQRS, việc thiết đặt lưu trữ Domain mã sản phẩm thực tế chỉ là một tuỳ chọn.

Lợi ích của sử dụng event sourcing: – soát sổ được audit log – có tác dụng tạo query nhằm truy vấn history data – Decoupled side-effects – cung ứng việc troubleshooting với debuging.

Xem thêm: Cách Chạy Lại Hệ Điều Hành Android Cho Samsung, Hướng Dẫn Chạy Lại Chương Trình Android

READ & WRITE model

WRITE model Trong bài toán xây dựng quy mô CQRS, câu hỏi xây dựng WRITE Model luôn là phức tập nhất, rất có thể coi WRITE mã sản phẩm như là trái tim của hệ thống. Ở đó tạo nên business decision quan liêu trọng. Nó xác định trách nhiệm chính của phong cách xây dựng này là biểu hiện state thực của hệ thống, state hoàn toàn có thể sử dụng để tạo nên các đưa ra quyết định quan trọng.

READ Model việc xử lý đọc tài liệu sẽ yêu cầu họ phải sử dụng những truy vấn. Thường xuyên thì những query số đông tốn không hề ít time (có thể do thực hiện truy vấn JOIN). Có nhiều cách để cải tiến vận tốc truy vấn (filter, hay tính toán trước tài liệu cần thiết,…). Mặc dù nhiên, thực tế công dụng nhất là áp dụng cache. Việc áp dụng cache tác dụng sẽ cần suy xét kỹ lưỡng. “There are only two hard things in Computer Science: cache invalidation & naming things. — Phil Karlton”