2015-11-28 14 views
7

Tôi đi qua một tuyên bố rằng mô hình miền được thiết kế phù hợp với DDD không nên được sử dụng làm tài nguyên trong API REST (source). Rõ ràng là REST API là một hợp đồng của ứng dụng trong khi mô hình miền là một phần của việc triển khai và do đó tốt nhất là giữ hai thứ này riêng biệt, để thay đổi trong mô hình miền không tự động ngụ ý một sự thay đổi trong REST API. Tuy nhiên, tôi nghĩ trong trường hợp các dự án nhỏ (API REST chỉ có một người tiêu dùng - giao diện javascript, được phát triển bởi một nhóm), lợi ích của việc có các mô hình riêng biệt không biện minh cho chi phí tách các mô hình (các lớp khác nhau). - mô hình tên miền và các biểu diễn tài nguyên và mã ánh xạ giữa các mô hình). Rõ ràng lớp miền không thể có bất kỳ tham chiếu nào đến mã cơ sở hạ tầng cụ thể REST (để giữ tách biệt các mối quan tâm).Tại sao mô hình miền không được sử dụng làm tài nguyên trong REST API?

Nếu tên miền và mô hình REST được tách ra?

Trả lời

8

Khi sử dụng DDD, API REST phải luôn được tách riêng khỏi mô hình miền.

Lý do chính cho việc này là đơn giản hóa - bạn không muốn làm rò rỉ sự phức tạp của mô hình miền thông qua API cho khách hàng. Nếu không, khách hàng cần phải biết về các sắc thái và phức tạp của miền của bạn, điều này có thể khiến API khó sử dụng.

Và trình điều khiển chính để sử dụng DDD là một miền có vấn đề phức tạp, vì vậy đây luôn là vấn đề.

Tuy nhiên, tôi nghĩ trong trường hợp các dự án nhỏ (& hellip;) không có chi phí tách mô hình (& hellip;).

Tôi đồng ý rằng có các dự án trong đó mô hình miền tách biệt và REST API quá kỹ thuật. Tuy nhiên, những trường hợp này không phải là ứng cử viên cho DDD, bởi vì bạn sẽ không được hưởng lợi từ DDD đủ để biện minh cho chi phí của nó.

1

Tôi nghĩ một điều nữa cần xem xét là ai sử dụng API REST của bạn. Nếu bạn đang phát triển giao diện người dùng cho ứng dụng thì bạn có thể nói rằng mọi thứ vẫn đang diễn ra trong 1 ngữ cảnh bị chặn. Chỉ một số phần cuộc sống trong khách hàng/javascript. Trong trường hợp đó tôi nghĩ rằng nó làm cho tinh thần để lộ mô hình của bạn trong api phần còn lại của bạn.

trong trường hợp đó, lệnh REST api có thể chỉ là phương tiện giao tiếp với dịch vụ miền của bạn chẳng hạn.

3

Tại sao mô hình miền không được sử dụng làm tài nguyên trong REST API?

Do web là một thế giới hoàn toàn khác với lớp miền cốt lõi của bạn. Các phương thức trong thực thể của bạn đặc biệt khó dịch vì HTTP chỉ có một số động từ. Nếu bạn muốn để lộ ứng dụng của bạn thông qua REST, bạn phải shoehorn quy trình miền của bạn thành HTTP và thường có nghĩa là làm cho thỏa hiệp và thiết kế các nguồn tài nguyên khác với các thực thể miền của bạn. Tất nhiên bạn nên tìm các thuật ngữ từ ngôn ngữ phổ biến trong các thông điệp trao đổi giữa máy khách HTTP và máy chủ và trong giao thức ứng dụng tên miền nếu bạn đang làm HATEOAS, nhưng trang web nhất thiết sẽ bóp méo các đại diện miền của bạn.

Điểm REST không phải là tạo lại một mô hình độ trung thực cao của miền của bạn và các quy trình của nó, nhưng để phân phối chúng theo cách tương thích HTTP trong khi mất ít nhất có thể trong bản dịch. Tuy nhiên, nó vẫn là một bản dịch.

0

Bạn có thể móc logic nghiệp vụ của mình vào tài nguyên REST dựa trên mô hình miền của bạn. Ví dụ: bất cứ khi nào ai đó đặt is_published = 1, bạn có thể thông báo cho quản trị viên, thực hiện xác thực bổ sung, v.v ... bằng cách móc vào một sự kiện hoặc một trình tắt. Đôi khi mọi thứ có thể quá phức tạp và kỳ lạ để làm theo cách đó, vì vậy bạn có thể gắn cờ các thuộc tính nhất định là không thể sửa đổi, sau đó tạo các hành động tùy chỉnh để sửa đổi chúng mà bạn trưng ra, nếu điều đó có ý nghĩa. Tôi nghĩ rằng nếu bạn thiết kế đúng cách bạn thậm chí không cần những "hành động tùy chỉnh" mặc dù. Facebook không sử dụng bất kỳ API đồ thị nào mà tôi không nghĩ. Tôi đang nghĩ về việc phát triển một khung công tác dựa trên việc chỉ hiển thị lớp Mô hình, tôi vẫn nghĩ đó là một ý tưởng hay.

Các vấn đề liên quan