O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Itlc hn 20150909 - le minh nghia - crud, ddd, cqrs, cqrs-es and op

1.597 visualizações

Publicada em

Chia sẻ kinh nghiệm:
Thiết kế hệ thống,
Tối ưu,
Domain Driven Design, CQRS,
Event Sourcing
ITLC HN 20150909 - Lê Minh Nghĩa - CRUD, DDD, CQRS, CQRS-ES
http://www.slideshare.net/vuhung16plus/itlc-hn-20150909-le-minh-nghia-crud-ddd-cqrs-cqrses-and-op

Cảm nhận:
https://tool.devsep.com/wiki/pages/viewpage.action?pageId=56928104
Những chủ đề như DDD là rất mới, trên cả thế giới và đặc biệt là ở Việt Nam
Tuy vậy, vẫn có rất nhiều công ty áp dụng và có thành công nhất định
Tối ưu hóa hệ thống là khó, liên quan đến nhiều vấn đề, chủ đề
Technical debt: Nếu không thiết kế tốt, có tầm nhìn thì debt rất lớn
Debt là điều không tránh khỏi. Ta chấp nhận và giảm thiểu nó tới mức nào thôi.

Project demo mô tả cách phân tích thiết kế phần mềm theo mô hình DDD, CQRS, CQRS-ES (.NET)
https://github.com/nghiaminhle/ddd-cqrs-cqrs-es

File gốc: https://docs.google.com/presentation/d/1E4z-JEKemH8VtoNAHO6QmbIhylKw9EoRcdBMHpphf-0/edit?usp=sharing

Publicada em: Internet
  • Seja o primeiro a comentar

Itlc hn 20150909 - le minh nghia - crud, ddd, cqrs, cqrs-es and op

  1. 1. Chia sẻ kinh nghiệm: Thiết kế hệ thống, Tối ưu, Domain Driven Design, CQRS, Event Sourcing Lê Minh Nghĩa, Toong, 8 Tràng Thi, Hà Nội 2015/09/09
  2. 2. Giới thiệu • Lê Minh Nghĩa • Phone: 0936 073 986 • Email: nghia.fit@gmail.com • Facebook: http://www.facebook.com/nghialeminh • Quá khứ: Doko.VN – Cty Mimas
  3. 3. Muốn giao lưu chia sẻ về • Enterprise Software Architecture • Domain Driven Design • CQRSCommand and Query Responsibility Segregation (CQRS) • Service Oritented Architecture (SOA) • Event Driven Architecture • High Performance Database • Data Mining • Cost Optimization
  4. 4. Các công việc đã, đang phụ trách • Tối ưu hóa hệ thống • Xây dựng giải pháp xử lý distributed transaction • Triển khai Enterprise Service Bus để tích hợp hệ thống • Triển khai kiến trúc hệ thống theo mô hình CQRS–ES. • Xây dựng process manager cho việc xử lý đơn hàng • Triển khai xử lý đơn hàng bất đồng bộ
  5. 5. Enterprise Software và các phương pháp phân tích thiết kế phần mềm
  6. 6. Enterprise Software là gì • Là các phần mềm phục vụ quản lý các doanh nghiệp như: công ty, cửa hàng, siêu thị, ngân hàng… • Không bao gồm các phần mềm về viễn thông, game, video… • Có rằng buộc dữ liệu chặt chẽ • Thường có luồng nghiệp vụ phức tạp • Không bị gắn chắt vào phần cứng
  7. 7. Demo đơn giản • Xây dựng một site hiển thị danh sách sản phẩm • Cho phép đặt đơn hàng • Đơn hàng có thể xác nhận hoặc hủy • Môt đơn hàng có tên sản phẩm và số lượng
  8. 8. “Hello” Enterprise Software • CRUD phương pháp đầu tiên để làm • Phân tích yêu cầu • Thiết kế CSDL • Cài đặt
  9. 9. Nhìn lại, có gì không ổn nhỉ • Gắn chắt với thiết kế CSDL • Không gần với đời sống • Dữ liệu không đóng gói • Khả năng kế thừa hạn chế • Khả năng bảo trì hạn chế
  10. 10. Chúng ta nghĩ gì và CRUD nói gì • Chúng ta nói tới các đối tượng, các thực thể • Phần mềm chúng ta nói tới các lệnh, các chức năng • Phần mềm chúng ta không mô hình hóa cái chúng ta hình dung
  11. 11. Domain Driven Design • Chúng ta hình dung ra sao phần mềm cần phải xây dựng như vậy • Cùng một model • Cùng một bộ ngôn ngữ • Dữ liệu và hành vi phải đi liền với nhau
  12. 12. Vấn đề khi xây dựng Enterprise Software
  13. 13. Vấn đề khi xây dựng Enterprise Software
  14. 14. Ubiquitous Language
  15. 15. Domain là gì • An area of knowledge or activity
  16. 16. Domain Model
  17. 17. Bounded Context
  18. 18. Bounded Context
  19. 19. Context Map
  20. 20. Domain Model & Bounded Context
  21. 21. Aggregate – Consistent Boundary
  22. 22. Phân tách tầng lưu trữ ra riêng rẽ
  23. 23. Cài đặt ra sao? • Đóng gói cao nhất • Không public set • Quên persistent, thiết kế model trước • Thiết kế data layer tách biệt domain • Thiết kế domain service • Thiết kế application service
  24. 24. Vậy lợi ích là gì? • Hiệu quả với các Bussiness phức tạp • Đáp ứng với sự thay đổi liên tục của Bussiness Logic • Các bên (dev, architect, domain expert) làm việc với nhau hiệu quả • Chi phí phát triển sau khi đã có core domain giảm
  25. 25. Còn có thể làm tốt hơn được không? • Đọc dữ liệu nhanh hơn • Đọc dữ liệu đơn giản hơn • Ít rằng buộc hơn • Sử dụng các schema khác nhau • Đồng thời ghi dữ liệu vẫn phải đúng nghiệp vụ
  26. 26. CQRS • Viết tắt: Command And Query Responsibility Segregation • Phân tách hai luồng riêng biệt: ghi dữ liệu và đọc dữ liệu • Sử dụng hai schema khác nhau
  27. 27. CQRS hình thù thế nào?
  28. 28. Make it Works • Command: một lệnh làm hệ thống thay đổi dữ liệu • Event: một sự thay đổi đã xảy ra • Command Bus: đường truyền các lệnh • Event Bus: đường truyền các event
  29. 29. Có cái gì đó xuyên suốt? – Event! • Mỗi sự thay đổi đều phát sinh event • Trạng thái của một đối tượng là một chuỗi các sự kiện xảy ra • Chạy lại event để tái tạo đối tượng
  30. 30. Event Sourcing • Lưu trữ nguồn event của một đối tượng • Xây dựng event store lưu trữ toàn bộ event của một object • Khi lưu một event đồng thời publish một event
  31. 31. Lưu trữ thế nào – Event Store • Xây dựng event store • Một bảng dữ liệu dùng để append event
  32. 32. CQRS - ES • CQRS kết hợp với ES dễ dàng • Mỗi command sẽ phát sinh một hoặc nhiều event • Các event được đánh version • Version của một object là version của event
  33. 33. Process Manager Pattern • Mô tả luồng nghiệp vụ là luồng các message • Cần một manager để điều hướng các luồng message
  34. 34. Event as the Core
  35. 35. State Machine Pattern • Lưu trữ state của hệ thống • Xây dựng luồng chuyển trạng thái • Tách phần quản lý trạng thái ra khỏi aggregate
  36. 36. State Matrix • Mô tả việc chuyển trạng thái dưới dạng ma trận • Dễ dàng quản lý • Logic rõ ràng
  37. 37. State Matrix
  38. 38. Thiết kế hệ thống phân tán có hiệu năng cao • Tránh tranh chấp dữ liệu • Tính toán trước • Sử dụng tài nguyên tính toán hợp lý
  39. 39. Nguyên lý CAP
  40. 40. Một case đơn giản mà không đơn giản • Xây dựng web service update CSDL đảm bảo strong consistency data
  41. 41. Distributed Transaction • Giao dịch với nhiều nguồn dữ liệu • Cần phải đảm bảo consistency • Giải pháp là gì
  42. 42. Two Phase Commit Thưc hiện hai phase: - Write - Commit Nếu lỗi: Undo tất cả Đòi hỏi: lock tất cả các resources
  43. 43. Eventually Consistency • Thay thế consistency bằng eventually consistency • Eventually consistency khắp mọi nơi • Không thể eventually tất cả nhưng hãy tối đa có thể
  44. 44. Hạn chế của kiến trúc hướng dịch vụ theo mô hình request - response
  45. 45. SOA theo mô hình Event Driven
  46. 46. Bất đồng bộ và bài toán tối ưu về hiệu năng và kinh tế • Bất đồng bộ tối đa có thể • Không cần scale tất cả các node • Tập trung tài nguyên tính toán cho node đòi hỏi hiệu năng cao
  47. 47. Sử dụng Message Bus để phân tách hệ thống
  48. 48. Các vấn đề cần chú ý • Khi nào CQRS phù hợp? • Hệ thống collobrative sysytem • Phải có nền tảng message ổn định • Cần phải giải quyết transation giữa message bus và database • Xác định tính chất Idempotent • Chú ý về thứ tự event • Xây dựng event store để không bị thắt cổ trai
  49. 49. Các giải pháp • Phân tích luồng nghiệp vụ thật cẩn thận • Chọn lựa nền tảng message bus có khả năng persistent và scale out tốt cũng như có khả năng điều hướng message tốt • Tránh tình trạng bị trùng lặp message hoặc có cơ chế phòng trừ • Xây dựng giải pháp partition và sharding data cho event store
  50. 50. Kết luận “Không thể scale được nếu không chia tách được”
  51. 51. Thank you. Q&A

×