Bài viết này là một ví đề xuất về quá trình và cách ra các quyết định thiết kế khi thiết kế một phần mềm.
Sản phẩm
Thực tế thì đây chính là quá trình thiết kế của sản phẩm có thật — trang web Clean Coders — một nơi mà Robert C. Martin — tác giả của chính case study này — bán các hướng dẫn phát triển phần mềm.
Ý tưởng rất đơn giản. Họ có một số lượng các video để bán. Họ bán, qua web, cho cả các cá nhân lẫn tổ chức. Người dùng cá nhân có thể trả tiền để xem stream của video, hoặc trả một mức giá khác cao hơn để có quyền tải và sở hữu các video đó. Các tổ chức thì chỉ có thể mua bản quyền để xem stream, và có khả năng mua số lượng lớn để có giá ưu đãi.
Các cá nhân thường vừa là người xem video vừa là người mua. Các tổ chức thì khác, họ thường có ai đó mua video để cho người khác xem.
Tác giả của các video cần có thể cung cấp các file video, viết mô tả cho chúng, làm rõ nội dung bằng các ví dụ, vấn đề, giải pháp, mã nguồn… và các tài nguyên khác.
Quản trị viên cần có thể tạo mới các chuỗi video, bổ sung hay xóa bỏ video khỏi chuỗi, cũng như định giá cho các bản quyền khác nhau.
Phân tích các Use Case
Hình dưới đây biểu thị các ca sử dụng điển hình.
Có bốn tác nhân chính hiển hiện. Chiếu theo Nguyên Tắc Đơn Trách Nhiệm, chúng sẽ là bốn nhóm chính gây ra các sự thay đổi trên hệ thống. Mỗi khi một chức năng mới được bổ sung, hay một chức năng cũ có thay đổi, sự kiện đó sẽ nhằm phục vụ một trong các tác nhân đó. Bởi vậy nên chúng ta chia hệ thống thành các mảng lớn sao cho sự thay đổi tới từ tác nhân này không ảnh hưởng tới bất kỳ đơn vị nào của tác nhân khác.
Để ý nét đứt rời của use case View Catalog, nó ngụ ý rằng đó là một abstract use case. Abstract use case là tập hợp các chính sách mang tính tổng quát mà use case khác sẽ tuân theo. Như chúng ta thấy là cả View Catalog as Purchaser và View Catalog as Viewer đều kế thừa abstract use case View Catalog.
Lên kiến trúc component
Sau khi biết được các actor và các use case, chúng ta có thể đi đến thiết kế sơ lược.
Trong sơ đồ dưới đây, các đường nét đôi vẫn thể hiện các biên kiến trúc như thường. Chúng ta có thể thấy sự phân lớp của các view, presenter, interactor, và controller. Chúng ta cũng có thể thấy các component đó được chia tách thành các nhóm dựa theo actor tương ứng của chúng.
Để ý component Catalog View và Catalog Presenter, chúng là cách tác giả đối xử với abstract use case View Catalog ở trên.
Nếu cần thiết, mỗi component trong sơ đồ có thể trở thành một file .jar, hay .dll trong tương lai. Mỗi component sẽ chứa các view, hay presenter, interactor, controller được phân bổ vào chúng. Hoặc chúng ta cũng có thể gom các component trong cùng biên kiến trúc lại, hoặc nhóm hai phạm vi kiến trúc (view + presenter chẳng hạn) lại với nhau… và nhiều phương án phát triển/deploy độc lập khác — nếu cần thiết.
Kiểm soát các mối phụ thuộc
Luồng điều khiển trong sơ đồ trên được thực thi từ phải sang trái. Thông tin đầu vào xảy ra tại các controller và được xử lý thành kết quả bởi các interactor. Các presenter sau đó sẽ định dạng lại các kết quả mà các view sẽ sử dụng để hiển thị.
Lưu ý rằng các mũi tên không nhất nhất tuân theo chiều từ phải sang trái như thế. Thực tế thì phần lớn chúng chỉ từ trái sang phải. Đó là bởi kiến trúc ở đây tuân theo luật phụ thuộc. Mọi mối phụ thuộc băng qua các đường biên kiến trúc theo cùng một hướng — về phía những component chứa chính sách cấp cao.
Để ý rằng các mối quan hệ sử dụng (đầu mũi tên mở) chỉ cùng chiều với luồng điều khiển, trong khi đó các mối quan hệ kế thừa (đầu mũi tên đóng) chỉ ngược chiều với luồng điều khiển. Điều này miêu tả sự vận dụng Nguyên Tắc Đóng-Mở trong việc đảm bảo các phụ thuộc chỉ theo đúng hướng, và để các thay đổi xảy ra ở chi tiết cấp thấp không gây đụng chạm tới nơi chứa các chính sách cấp cao.
Kết luận
Sơ đồ trên có hai chiều hướng phân tách. Một chiều dựa trên các actor khác nhau, theo Nguyên Tắc Đơn Trách Nhiệm; một chiều khác bởi Luật Phụ Thuộc. Mục tiêu của cả hai là một sự phân tách hệ thống thành các component mà thay đổi bởi những nguyên nhân khác nhau, theo những tần suất khác nhau. Sự khác nhau bởi nguyên nhân là tương ứng với các actor, và sự khác nhau ở tần suất là tương ứng với cấp độ chính sách.
Một khi hệ thống được phân tách theo cách này, chúng ta có thể tùy biến quá trình deploy theo cách chúng ta muốn. Nhóm các component theo các đơn vị chuyển giao theo bất kỳ cách nào hợp lý, và dễ dàng thay đổi cách gom nhóm khi cần.
