Phân vùng tài nguyên API REST thành các khu vực dựa trên các lĩnh vực kinh doanh

Trong một API REST ứng dụng chính bao gồm một số miền liên quan, việc phân chia tài nguyên thành 'khu vực' dựa trên miền doanh nghiệp mà chúng thuộc về hay tốt hơn là duy trì một mô hình duy nhất?

Ví dụ: có các tên miền phụ 'Bán hàng' và 'Hàng tồn kho'. Người dùng của hệ thống thường chỉ quan tâm đến một tên miền tại một thời điểm, nhưng ngoại lệ là có thể. Có một khái niệm 'Mục' tồn tại trong cả hai miền để chúng tôi có thể triển khai tài nguyên 'mục' theo hai cách khác nhau.

1. có các tài nguyên khác nhau để thể hiện khái niệm trong mỗi miền, mỗi tài nguyên chỉ chứa dữ liệu liên quan:

   / doanh số / mặt hàng /: id

   / hàng tồn kho / vật phẩm /: id

2. có một tài nguyên với tất cả dữ liệu sẽ được sử dụng trong tất cả các bối cảnh:

   / mục /: id

Ngoài ra còn có rất nhiều tài nguyên chỉ thuộc về một trong các miền.

ưu điểm của 'khu vực'

• dễ hiểu hơn về API cho người dùng chỉ quan tâm đến một tên miền
• dễ dàng thực hiện các tài nguyên hơn (ít công cụ hơn để đọc / cập nhật tại một thời điểm)
• tài nguyên có thể được chuyên biệt hóa / tối ưu hóa hơn cho từng miền cụ thể
• khả năng kiểm soát truy cập vào tài nguyên ở cấp độ chi tiết hơn

ưu điểm của một mô hình thống nhất

• không có tài nguyên trùng lặp cho các khái niệm thuộc về nhiều hơn một miền
• nếu người dùng cần làm việc với nhiều tên miền, anh ta sẽ chỉ phải sử dụng một API duy nhất đáp ứng tất cả các nhu cầu của anh ta

Phân vùng API như được mô tả ở trên có phải là cách hợp lệ để giảm độ phức tạp của cả hợp đồng và triển khai API không? Tôi chưa thấy nó được đề cập nhiều ở bất cứ đâu.

Có thêm điều gì cần được xem xét để đưa ra quyết định có lợi cho một trong hai cách tiếp cận không?

Tôi nghĩ rằng đây là sự phù hợp hoàn hảo cho mẫu Bounded Context từ Domain Driven Design.

Các mô hình lớn không có quy mô tốt, tốt hơn là chia chúng thành các mô hình nhỏ hơn (bối cảnh bị ràng buộc) và tuyên bố rõ ràng mối quan hệ của chúng (các thực thể chung, tương tác giữa các bối cảnh bị ràng buộc, v.v.)

Trong trường hợp này, bạn sẽ có hai bối cảnh giới hạn (bán hàng và hàng tồn kho) với một tài nguyên được chia sẻ (mục). Giải thích mặt hàng trong bối cảnh bán hàng có thể hơi khác so với bối cảnh hàng tồn kho và điều đó hoàn toàn tốt.

Để sử dụng mẫu này, bạn nên:

• xác định ranh giới của các bối cảnh khác nhau (mà bạn đã thực hiện một phần bằng cách tạo các kênh con / doanh số / và / hàng tồn kho /)
• xác định các tài nguyên được chia sẻ (mục) và mô tả rõ ràng diễn giải của tài nguyên trong các bối cảnh bị ràng buộc khác nhau là gì
• xác định các tương tác giữa các bối cảnh bị ràng buộc (có thể nằm ngoài phạm vi của câu hỏi này)

Lưu ý về

ưu điểm của một mô hình thống nhất duy nhất: không có tài nguyên trùng lặp cho các khái niệm thuộc về nhiều hơn một miền

Từ quan điểm REST, tài nguyên không bị trùng lặp. Một tài nguyên có thể được xác định bởi nhiều URI, mỗi URI có thể có các biểu diễn khác nhau (phù hợp với bối cảnh giới hạn nhất định).

Tôi nghĩ rằng quy tắc của ngón tay cái nên như sau.

Nếu một mặt hàng là không thể tưởng tượng mà không liên quan đến bán hàng hoặc hàng tồn kho, bạn nên đi đến tùy chọn 1.

Nếu một mặt hàng có thể tồn tại mà không có bất kỳ mối quan hệ nào với doanh số / hàng tồn kho hoặc mối quan hệ này không thực sự mạnh mẽ trong kiến ​​trúc của bạn, bạn có thể chọn tùy chọn 2.