CQRS pattern - Thiết kế kiến trúc CQRS Command Query Responsibility Segregation

 Command : câu lệnh, ở đây có thể hiểu là các Task, CronJob chạy ngầm

Query : Việc thao tác với cơ sở dữ liệu

Responsibility : Chịu trách nhiệm

Segregation : chia tách

Nói đơn giản là Thiết kế cấu trúc hệ thống gồm hai phần riêng biệt : 

- Chỉnh sửa dữ liệu chạy riêng

- View dữ liệu chạy riêng





Ví dụ 1 use case như sau : bạn làm 1 app quản lý các order ( đơn đặt hàng) của 1 nhà hàng online. Đơn đặt hàng này dựa trên các thông tin có liên quan sau : 

1- Khách hàng ( ví dụ người đặt hàng)

2- Menu ( đặt món gì)

3 - Bếp (Bếp đã hoàn thành món ăn ngày giờ nào...)

4 - Delivery, Ship ( Đã ship đến cho khách chưa, ...)

5- Kế toán ( Khách đã trả tiền, thanh toán chưa...)

... vân vân và mây mây

App này có yêu cầu hiển thị chi tiết về đơn hàng như sau


Mã đơn hàng Người đặt Ngày đặt Địa chỉ ship Tình trạng đơn hàng Số tiền đã thanh toán
OD0001 Nguyễn Văn A Ngày đẹp trời Nhà mặt phố Đã ship xong 100k
OD0002 Nguyễn Văn B ... ... Bị Hủy Hủy rồi thì tiền nong gì?

Ví dụ để ra một bảng báo cáo như thế này về các đơn hàng, theo cách thiết kế cũ, chúng ta sẽ làm như sau


1 - Thiết kế các bảng gồm

1.1 Bảng khách hàng

1.2 Bảng Menu 

1.3 Bảng Delivery

1.4 Bảng Order

...

2- Viết các service cập nhật dữ liêu cho từng bảng

3 - Viết 1 service order, vừa cập nhật trạng thái bảng order, vừa query join các bảng để ra được báo cáo trên

Việc này thì không gì sai, thực ra nhiều ứng dụng vẫn làm cho đến khi dữ liệu trở nên ngày một lớn, và đòi hỏi các báo cáo trở nên phức tạp hơn, lúc đó ngồi nặn óc viết câu query, join các bảng là 1 việc rất khó khăn, nhức đầu, ....


Để khắc phục nhược điểm này, mô hình CQRS ra đời, về cơ bản sẽ như sau

1 - Tất cả những service liên quan đến cập nhật dữ liệu được thiết kế riêng

2- Những service nào có trách nhiệm lấy dữ liệu để hiển thị được thiết kế riêng

và những service này được chạy dưới dạng các command ( có thể hiểu là các thao tác chạy ngầm, được gọi tuần tự trên quêue, hoặc cronjob,...). Cụ thể như sau


Khi Có đơn đặt hàng từ khách, những thông tin sau sẽ được lưu ở 1 bảng riêng, hoặc 1 cơ sở dữ liệu riêng biệt (cái này tùy theo thiết kế của bạn),  được gọi là Materialized View 

View này lưu các thông tin như ở bảng trên. Chúng ta thiết kế các command như sau

Command 1 : chạy Order service, sau khi lưu xong các thông tin liên quan đến order (mã order, ngày đặt)

Command 2  : chạy Customer service, lưu các thông tin liên quan đến Khách hàng

....

Các command này chạy ngầm

cuối cùng sẽ có 1 command, ví dụ như

Command n : chạy OrderReport service, sẽ tổng hợp lại thông tin của các command 1,2...n-1 đã chạy, và lưu ra Materialized View


Việc cuối cùng của chúng ta là đọc thông tin từ Materialized View và hiển thị


Các bạn có thể tìm hiểu thêm tại

https://microservices.io/patterns/data/cqrs.html

https://viblo.asia/p/tim-hieu-command-and-query-responsibility-segregation-pattern-WAyK8o4o5xX

Comments

Post a Comment

Popular posts from this blog

Các câu hỏi liên quan đến restful API

Image
  Một câu hỏi khá đơn giản trong quá trình phỏng vấn là 1- What is restful API với câu hỏi này bạn nên có 3 ý chính :  1.1 - Nó là 1 API (application program interface) 1.2 - Nó hoạt động dựa trên HTTP 1.3- Nó cung cấp các method để thao tác với dữ liệu gồm GET, POST, PUT, DELETE 2 - Khác nhau giữa PUT và Patch PUT : update if exist id, or create new Patch : Update if exist id or throw an exception 3 - Json standard in Restful API 3.1 Use nouns instead of verbs in endpoint paths 3.2 Use logical nesting on endpoints /articles /article/id/comments 3.4 -  Handle errors gracefully and return standard error codes Common error HTTP status codes include: 400 Bad Request – This means that client-side input fails validation. 401 Unauthorized – This means the user isn’t not authorized to access a resource. It usually returns when the user isn’t authenticated. 403 Forbidden – This means the user is authenticated, but it’s not allowed to access a resource. 404 Not Foun...
Read more

Active record (Eloquent) trong Laravel và Data Mapper (Doctrine) trong Symfony

 Khi tao tác với DB trong Laravel và Symfony, có thể bạn sẽ làm việc với Eloquent hoặc Doctrine. Vậy sự khác nhau là gì Active Record Doctrine class User extends Eloquent { } Như vậy active record là một object được kế thừa từ Eloquent use Doctrine \ ORM \ Mapping AS ORM ; /** * @ORM\Entity * @ORM\Table(name="users") */ class User { /** * @ORM\Id * @ORM\GeneratedValue * @ORM\Column(type="integer") */ private $id ; /** * @ORM\Column(type="string") */ private $name ; } Trong doctrine, data mapper thực chất là 1 PHP Opject đơn thuần    $user = User :: find ( 123 ) ; $user -> name = 'Philip Brown' ; $user -> save ( ) ; Khi thao tác với DB, các dùng active record khác trực quan và đơn giản vì bản thân class User được kế thừa từ Eloquen, nên bạn có thể thao tác trực tiếp với DB thông qua Class User Câu lệnh save ở trê...
Read more

CI/CD diagram, infra

Image
 Trong quá trình phỏng vấn, có thể các bạn sẽ gặp một số câu hỏi liên quan đến devops ví dụ như - Bạn deploy code trên hệ thống như thế nào? - Bạn có thể nói qua về infrastructure của dự án được không? ... Sau đây là diagram, các bạn có thể tham khảo  1 - Cluster config repo Đây là 1 repo nơi bạn chứa cấu hình tất cả thông tin liên quan đến infra, ví dụ DB server, db name, users,... Một thao tác đơn giản nhất là khi bạn muốn tạo 1 db mới, bạn chỉ cần vào Cluster config repo này ( ví dụ file  mysql-prod.yaml) thêm các cấu hình DB cần thiết, sau đó push file này lên. Việc còn lại sẽ có 1 software là Puppet làm 2 - Puppet Là 1 phần mềm dùng để provisioning cho infra của các bạn. Có thể hiểu nôm na phần mềm này sẽ set up cho bạn 1 infra dựa trên những cấu hình có được từ Cluster config 3 - Actor Người dùng Ví dụ khi người dùng truy cập trang abc.com, thì request này sẽ được route đến Load Balancer (Cân Bằng Tải) 4 - Load Balancer Cân bằng tải, tiếp nhận các request từ người d...
Read more