Tôi có một mô tả chức năng hệ thống thực hiện tạo đơn hàng như sau:
- Tiếp nhận yêu cầu tạo đơn
- Kiểm tra tồn kho từng sản phẩm
- Tính toán và tạo mới đơn hàng
- Lưu xuống database
Mô tả trên chính là các ràng buộc, luật lệ mà hệ thống cần phải thực hiện. Hay nói cách khác, chúng là các chính sách của hệ thống.
Chính sách quy định hệ thống và nó không phải là duy nhất. Mỗi hệ thống tuyên bố những tập chính sách khác nhau, có chính sách ở mức cao, có chính sách ở mức thấp. Bạn có thể tưởng tượng nó như quy định pháp luật.
Quy định giao thông: "Người tham gia giao thông phải tuân thủ các giới hạn tốc độ do luật định".
Bên trên là một quy định hay một chính sách quy định rất tổng quát. Ta sẽ đặt ra câu hỏi như "tốc độ bao nhiêu là giới hạn? xe máy và ô tô có khác nhau không?" và nhiều câu hỏi khác nữa. Khi đó, ta có những chính sách cụ thể hơn, làm rõ hơn: "Khu vực đô thị: giới hạn 50 km/h. Ngoài đô thị: giới hạn 80 km/h,..." Rõ ràng, quy định đầu tiên ở mức chính sách cao hơn so với hai quy định sau.
Cấp của chính sách dựa vào khoảng cách của nó tới input/output:
- Chính sách càng cao khi nó càng xa input/output và ngược lại,
- Chính sách càng thấp khi nó càng gần input/output.
Quay lại ví dụ tạo đơn hàng, ta có mô hình biểu diễn cách thành phần như sau:
Trong hình trên:
Số (1), (2),... thể hiện thứ tự của luồng dữ liệu.
Mũi tên nét liền thể hiện data flow.
Mũi tên nét đứt thể hiện sự phụ thuộc về source code.
Hai loại mũi tên này không phải lúc nào cũng có hướng trùng nhau.
Nhận xét các chính sách:
-
Create Order: có cấp độ cao nhất bởi nó ở đỉnh của luồng xử lý, do đó, nó cách input và output xa nhất.
-
Validate Stock: có cấp độ thấp hơn Create Order một bậc do nó ở gần Input/output hơn.
-
Read Order Request, Save Order, và Update Stock: đều ở mức chính sách thấp nhất do chúng rất gần với input và output.
Nghiệp vụ Create Order không cần quan tâm tới việc dữ liệu đầu vào để tạo Order tới từ đâu. Nó chỉ đơn giản là chìa bàn tay ra và tiếp nhận dữ liệu đó. Create Order sẽ cần validate thông tin từng stock trong yêu cầu tạo. Nó cũng chỉ cần gọi tới thành phần chịu trách nhiệm thực hiện việc đó: Validate Stock. Như vậy, Create Order làm việc hoàn toàn với các đối tượng trong chương trình mà không hề phụ thuộc vào tầng công nghệ như database, messaging, web service nào khác. Nó ở mức chính sách cao nhất trong bức tranh này.
Về Validate Stock, tiếp nhận yêu cầu validate từ Create Order và thông qua Update Stock để giao tiếp với tầng lưu trữ, nhờ đó nó mới thực hiện được yêu cầu của mình. Validate Stock sẽ xa tầng lưu trữ hơn Update Stock, do đó, nó ở mức chính sách cao hơn Update Stock. Sở dĩ Validate Stock ở mức chính sách thấp hơn Create Order vì bạn thấy nó có một mũi tên source code dependecy trỏ vào Create Order.
Read Order Request là tầng thấp hơn Create Order vì nó tiếp xúc gần hơn với yêu cầu từ người dùng. Nó có thể tiếp nhận yêu cầu từ một web service, một GUI, hay một thành phần xử lý file excel. Tương tự thể, Save Order thông thường sẽ giao tiếp với một database. Do đó, nó cũng ở mức thấp hơn Create Order.
Tính nghệ thuật trong thiết kế phần mềm (gọi là "nghệ thuật" vì ta không có số đo cụ thể) là: ta cần bóc tách các chính sách ra và gom những thứ có thể lại với nhau dựa trên cách mà chúng thay đổi. Việc sắp xếp này không dừng lại một khi phần mềm của ta vẫn còn được cập nhật. Do đó, việc tái cấu trúc một hệ thống là một quá trình đi cùng với sự phát triển của hệ thống đó. Vậy cách mà các chính sách thay đổi là gì để ta căn cứ vào đó để gom chúng lại với nhau? Dựa vào hai căn cứ sau:
- Các chính sách thay đổi cùng nhau, và
- Chúng thay đổi tại cùng thời điểm.
Nếu bạn đã biết về Common Closure Principle - CCP thì bạn không còn lạ về hai căn cứ này. Những chính sách khác biệt ở hai căn cứ này, ta nên tách nó ra để hình thành những thành phần khác.
Chính sách trong hệ thống phần mềm là một trong những yếu tố dẫn dắt chúng ta trong quá trình thiết kế hệ thống