Mr Lê Minh Nghĩa - Solution Architect from Tiki

1. Domain Driven Design và Event Driven
Architecture
trong xây dựng Enterprise Software
Lê Minh Nghĩa
Solution Architect from Tiki
22/10/2016

2. Giới thiệu về bản thân
• Lê Minh Nghĩa
• Solution Architect – tiki.vn
• Email: nghia.fit@gmail.com
• Facebook: /nghialeminh

3. Các nội dung chính
1. Các yêu cầu đặt ra
2. Ứng dụng Domain Driven Design
3. Event - driven Architecture
4. Một số Case Studies
5. Kết luận
3

4. 1. Các yêu cầu đặt ra
• Khả năng mở rộng về mặt nghiệp vụ.
• Khả năng mở rộng về mặt hiệu năng
4

5. 1.1. Khả năng mở rộng về nghiệp vụ
• Nghiệp vụ luôn luôn thay đổi. Thiết kế là để đáp ứng nhu cầu thay đổi.
• Có model dữ liệu phải nhất quán và rõ ràng
• Logic nghiệp vụ phải tập trung
• Cấu trúc thống nhất
• Mọi thành phần đều có thể thay thế.
• Tiếp cận: Domain Driven Design
5

6. 1.2. Mở rộng về mặt hiệu năng
• Không dùng chung một mô hình xử lý
• Đảm bảo khả năng tích hợp và mở rộng
• Đảm bảo tính ổn định trong môi trường phân tán.
• Tiếp cận: Event driven Architecture
6

7. 1.3. Mô hình kiến trúc
7
Database
Message Queue Caching

8. 2. Ứng dụng Domain Driven Design
• Khó khăn khi phát triển
• Thiết kế Aggregate
• Infrastructure Layer
• Mức độ tái sử dụng
8

9. 2.1. Khó khăn khi phát triển
• Không có model dữ liệu nhất quán.
• Trùng lặp mã nguồn lớn
• Khó kiểm soát khi nghiêp vụ bùng nổ
• Không có cấu trúc API thống nhất
• Khó đảm bảo tính nhất quán
9

10. 2.2. Aggregrate
Là một nhóm các đối tượng dữ liệu được đối xử như một thể thống nhất
trong hệ thống
VD: order và order line phải coi như là hai thành phần nhất quán của
đối tượng aggregate order, định danh trong hệ thống là order id.
10

11. 2.2. Aggregrate
11

12. 2.2. Aggregrate
- Đảm bảo cách nhìn thống nhất trong toàn bộ hệ thống
- Khi nói đến một aggregate phải nói tới một đối tượng dữ liệu toàn vẹn,
đầy đủ.
- Không tồn tại các nghiệp vụ riêng biệt với từng thành phần của một
aggregate
- Tất cả logic từ data access tới service đều phải xoay quanh các
aggregate
12

13. 2.2. Aggregate
• Chọn lựa phạm vi aggregate vừa đủ.
• Phạm vi aggregate quá lớn sẽ dẫn tới performance không tốt.
• Phạm vị aggregate quá bé sẽ dẫn tới logic bị phân mảnh và khó quản
lý.
• Đảm bảo các thành phần của một aggregate luôn nhất quán
13

14. 2.2. Aggregate
 Sử dụng pattern về data access thống nhất:
– Repository Pattern
– ORM
 Cấu trúc resources API tương ứng với các Aggregate
14

15. 2.2. Aggregate
Don’t Repeat Yourself:
• Không nhầm lẫn Aggregate và các DTO
• Không design API dựa theo nhu cầu hiển thị
• Không xây dựng data access theo từng chức năng.
15

16. 2.3. Infrastructure Layer
Database
Message Queue Caching
16

17. 2.3. Infrastructure Layer
• Đảm nhiệm vai trò làm việc với các thành phân bên dưới như DB,
Message Queue, File…
• Phần lớn logic của hệ thống là logic nghiệp vụ
• Không để logic của phần infrastructure làm giảm tốc độ phát triển
của nghiệp vụ
17

18. 2.3. Infrastructure Layer
• Phải có khả năng tái sử dụng cao
• Phai nhất quán trong toàn bộ cấu trúc hệ thống
• Pattern:
- Repository Pattern
- Observer Pattern
- ORM Pattern
18

19. 2.4. Mức độ tái sử dụng
Applications – Web App, API, Server Application…
Application Service
Domain Service
Domain Model
Infrastructures
19
Mức độ sử dụng

20. 2.4. Mức độ tái sử dụng
• Các layer càng cao thì càng được sử dụng nhiều.
• Các layer càng bên dưới thì càng phải tái sử dụng cao
• Tránh thiết kế để độ phức tạp là ngang nhau giữa tất cả các layer.
• Tốc độ phát triển ngày một nhanh, vì tích lũy được các logic trước đó.
• Phải luôn kiểm soát, refactor mã nguồn.
• Phải ám ảnh triết lý: Don’t Repeat Yourself!
20

21. 3. Event – Driven Architecture.
• Yêu cầu mở rộng về mặt hệ thống
• Event Drivent Archtecture trong Distributed System
• Message Bus/Event Bus
• Event Sourcing
• Tích hợp hệ thống
• Đảm bảo thứ tự message
21

22. 3.1. Yêu cầu mở rộng hệ thống
• Không chia được thì không scale được
• Scale độc lập nhiều thành phần
• Giải quyết tính ổn định trong tích hợp hệ thống
22

23. 3.2. EDA trong Distributed System
Request Driven Architecture
23

24. 3.2. EDA trong Distributed System
Request Driven Architecture:
• Phức tạp khi tích hợp hệ thống
• Rất khó để quản lý tính nhất quán của dữ liệu
• Khó để mở rộng độc lập các thành phần của hệ thống
24

25. 3.2. EDA trong Distributed System
25
Event Driven Architecture

26. 3.2. EDA trong Distributed System
 Event Driven Architecture
- Lose couping toàn bộ hệ thống
- Dễ dàng tích hợp
- Quản lý luồng message
26

27. 3.3. Message Bus
• Đóng vai trò truyền gửi message trong hệ thống
• Đảm bảo quá trình truyền gửi ổn định
• Có khả năng điều hướng message
• Dễ dàng tích hợp với các thành phần trong hệ thống.
• Là đối tượng về mặt logic của các hạ tầng message queue
27

28. 3.3. Message Bus
Logistic
System
Operation
Data
Warehouse Tracking Optimize
Message Bus

29. 3.3. Message Bus
Có thể trừu tượng hóa thành hai loại:
- Event Bus : truyền gửi các event đã xảy ra
- Command Bus: truyền gửi bất đồng bộ các lệnh thay đổi dữ liệu trong
hệ thống.
29

30. 3.4 Event Sourcing
30

31. 3.4 Event Sourcing
• Lưu trữ thay đổi của đối tượng
• Tách các phần ghi và đọc trong hê thống
31

32. 3.4 Event Sourcing và thực tế áp dụng
• Việc xây dựng cấu trúc lưu trữ Event Store cho tất cả là phức tạp
• Kiểm soát tính đồng thời trong các thao tác cập nhật khó khăn
• Phân tích read side thành nhiều thành phần tùy theo yêu cầu về tính
nhất quán và đồng thời với write side.
• Nên dùng Event Store để lưu log hơn là main database.
32

33. 3.4 Event Sourcing và thực tế áp dụng
Ví dụ: Cập nhật trạng thái đơn hàng:
- Nếu cần lấy ngay trạng thái thành công hay thất bại để hiển thị  sử
dụng chung một mô hình lưu trữ cho hai việc
- Nếu sau khi cập nhật tác động tới dữ liệu ở khâu vận hành khác 
read side là cấu trúc lưu trữ phục vụ khâu vận hành
33

34. 3.5. Đảm bảo thứ tự của message
• Đảm bảo thứ tự message có vai trò quyết định với tính ổn định của
toàn hệ thống
VD: để tracking trạng thái hàng hóa, khi vận hành có hai event:
- e1: nhập kho
- e2: xuất kho
Các event gửi trong môi trường phân tán, thứ tự e1, và e2 có thể bị đảo
lộn.
Khi số lượng event càng lớn, thì tỉ lệ lỗi càng cao, ảnh hưởng độ ổn định
hệ thống.
34

35. 3.5. Đảm bảo thứ tự message
• Đảm bảo thứ tự ghi dữ liệu
• Đảm bảo thứ tự gửi event
• Đảm bảo thứ tứ nhận event
35

36. 3.5.1. Đảm bảo thứ tự ghi
• Các event được append vào một log. Ví dụ: insert vào một table.
• Các lệnh insert thường không lock nhau, do đó các lệnh insert có thể thực thi đồng
thời.
VD:
- Thời điểm T1: lấy order và xử lý
Process 1: Get Order – version = 1
DoSomething()
version = version + 1  2  event E2
Process 2: Get Order – version = 1
DoSomething()
version = version + 1  2  event E2
- Thời điểm T2: lưu kết quả xử lý: lưu các event lại.
Do các lệnh insert không lock nhau, nên lưu trữ sẽ là: E1 – E2 – E2
Wrong!
36

37. 3.5.1. Đảm bảo thứ tự ghi
 Solution 1: lock theo key range, sử dụng transaction mode lock
serializable
Ví dụ: lock theo key là id order
 Solution 2: sử dụng hai resources:
R1: snapshot của object
R2: event log
Lock lệnh update trên R1 và append vào R2
 Solution 3: nếu lưu event trên table, thì sử dụng bộ cặp primary key
của event:
Aggregate Id – Version
Các event cùng version sẽ bị đụng độ khi insert.
37

38. 3.5.2. Đảm bảo thứ tự gửi
Các message có thể bị gửi sai thứ tự, dù thời điểm xử lý diễn ra đúng thứ
tự.
VD:
- Thời điểm T1:
DoSomething();
Send Event 1;
- Thời điểm T2:
DoSomething();
Send Event 2;
Event 1 send đi lỗi, Event 2 lại send thành công  Wrong!
38

39. 3.5.2. Đảm bảo thứ tự gửi
Solution:
- Không áp dụng đồng thời ghi DB và gửi event vì không có transaction.
- Phải gửi log các event trước khi gửi đi
- Gộp nhóm các event theo id của aggregate phát event. Lưu trữ event với
cặp key: aggregateId – version
- Load các event cần gửi theo aggregate id, và gửi tuần tự theo version
- Dừng gửi ngay khi gặp event lỗi
- Xử lý sự cố  Load lại theo aggregateId và gửi tiếp theo thứ tự version
- Sử dụng hai bảng:
• Bảng Event để store event
• Bảng Undispatched Event để lưu tạm các event chờ gửi, sẽ xóa sau khi gửi xong.
39

40. 3.5.2. Đảm bảo thứ tự gửi
ID Version
ABC 3
XYZ 2
40
ID Version Payload
ABC 1 ….
ABC 2 ….
ABC 3 ….
XYZ 1 ….
XYZ 2 ….
Order
Event
ID Version Payload
ABC 1 ….
ABC 2 ….
ABC 3 ….
XYZ 1 ….
XYZ 2 ….
Undispatched Event

41. 3.5.3. Đảm bảo thứ tự nhận message
Các message khi được dequeue song song có thể sẽ bị mất thứ tự khi
xử lý:
• T1: message 1 dequeue và P1 process
• T2: message 2 dequeue và P2 process
Vì P1 xử lý lâu hơn P2 nên P2 commit trước  Wrong!
41

42. 3.5.3. Đảm bảo thứ tự nhận message
• Gom nhóm các message theo một định danh: ví dụ aggregate id
• Các message của một nhóm chỉ được nhận bởi một thread tại một
thời điểm
• Tận dụng các tính năng Partition của Kafka hoặc Session của Windows
Service Bus để đảm bảo thứ tự message khi routing
42

43. 3.6. Tích hợp hệ thống.
• Message Bus giúp đơn giản quá trình tích hợp message
• Các thành phần tích hợp dựa trên nền tảng message bus
43
Context A Context B
Message Bus

44. 3.6. Tích hợp hệ thống.
• Giữa các context không nên biết tới thành phần sẽ consumer
message của nó
• Logic luồng message khác với logic thực thi tại từng thành phần
• Các context khác nhau yêu cầu các định dạng message khác nhau
44

45. 3.6.1. Process Manager
• Dùng để giải quyết vấn đề điều phối giữa các luồng message
• Đóng vai trò là thành phần trung tâm trong việc tổ chức logic của
luồng message
• Không xử lý logic nghiệp vụ, chỉ làm logic điều phối luồng.
• Phát huy vai trò lớn khi các logic luồng phức tạp.
45

46. 3.6.2. Process Manager
46
Context A Context B
Message Bus
Process
Manager

47. 3.6.3. Translator Pattern
• Đóng vai trò chuyển đổi message thành các định dạng phù hợp với
consumer
• Tách logic phát message khỏi logic transform message
47
Context A Context B
Message Bus
Translator B

48. 4. Case Studies
• Một số yêu cầu cơ bản của bàn tài toán giao vận.
• Xác định các đối tượng dữ liệu cơ bản
• Xây dựng cấu trúc đầu tiên
• Apply Event Sourcing
• Event Handler/Command Handler
• Mô hình hệ thống
48

49. 4.1. Các yêu cầu cơ bản.
• Quản lý các đối tượng hàng hóa: đơn hàng, gói hàng, carton…
• Quản lý luồng nghiệp vụ đơn hàng: gom hàng, nhặt hàng, xuất
nhập…
• Theo dõi trạng thái đơn hàng
• Báo cáo và phân tích
49

50. 4.2. Các đối tượng cơ bản
50
SO
Items
Package
Items
Carton
Items

51. 4.3. Xây dựng cấu trúc đầu tiên
51
Application
Infrastructures
Application Service
Domain Service
Domain Model

52. 4.3.1. Domain Models
52
public partial class SO : EventSourced, IStateContext
public partial class Package : EventSourced, IStateContext
public partial class Carton : EventSourced, IStateContext

53. 4.2.2. Infrastructure
53
public interface IRepository<Context> where Context : DbContext
{
void Save<T>( T aggregate ) where T : class;
T Find<T>( object id ) where T : class;
IQueryable<T> Get<T>( Expression<Func<T, bool>> predicate ) where T :
class;
}

54. 4.2.3. Domain Services
54
public class PackageService : IPackageService
{
private readonly Func<IRepository<DbContext>>
repositoryFactory;
public Package CreatePackage(CreatePack param)
{
Package package =
createActivity.MakePackage(param);
repository.Save<Package>(package);
repository.SaveChanges();
return package;
}
}

55. 4.3. Apply Event Sourcing
• Quản lý các đối tượng trạng thái các đối tượng hàng hóa để theo dõi
• Xây dựng model cho việc lưu trữ event
• Thay đổi tầng lưu trữ để đảm bảo không thay đổi tầng logic
55

56. 4.3.1. Xây dựng model cho event
56
Event Sourced
- ListPendingEvent (VersionEvent)
- Version: integer
- RaiseEvent(Event)
SO CartonPackage
VersionEvent
- SourceId: Guid
- Version: integer
StateChan
ed Event

57. 4.3.1. Xây dựng model cho event
57

58. 4.3.1. Xây dựng model cho event
58

59. 4.3.3. Thay đổi Infrastructure
• Lưu trữ thay đổi thì gửi event đi
• Chỉ thay đổi tầng Repository
59

60. 4.3.3. Thay đổi Infrastructure
60

61. 4.3.3. Domain Service giữ nguyên
• Chi cấu hình Dependency Injection lại Repository, giữ nguyên logic
61

62. 4.3.4. Event Handler/Command Handler
62
Event Bus
Message Receiver
Message Dispatcher Command Dispatcher
Infrastructures
Domain Service
Comand Handler Event Handler

63. 4.3.4. Event Handler/Command Handler
63

64. 4.5. Mô hình hệ thống
64
Command/Event Bus
Carton
Processing
Tracking
System
SO
Processing
Data
Warehoouse
Package
Processing
Routing
Optimize

65. 5. Kết luận
1. DDD giúp có một cấu trúc tách bạch, rõ ràng
2. Phải thiết kế để mọi thành phần đều có thể thay
thế và mở rộng
3. Event Drivent Architecture phù hợp để scaling mở
rộng hệ thống.
4. Sử dụng một model thống nhất
5. Xây dựng tách bách infrastructure với business layer
65

66. Xin chân thành cám ơn!