Có thể thực hiện giao diện DDD và REST và lập bản đồ ngôn ngữ không?

Question

REST có một ràng buộc giao diện đồng nhất, sau đây là một định dạng dựa trên ý kiến ​​rất nén.

• Bạn phải sử dụng các tiêu chuẩn như HTTP, URI, MIME, vv ...
• Bạn phải sử dụng các siêu liên kết.
• Bạn phải sử dụng từ vựng RDF để chú thích dữ liệu và siêu liên kết với ngữ nghĩa.
• Bạn làm tất cả những điều này để tách riêng khách hàng khỏi các chi tiết triển khai của dịch vụ.

DDD với CQRS (hoặc không có nó) rất giống với tôi hiểu.

• Bởi CQRS bạn xác định giao diện để tương tác với mô hình miền. Giao diện này bao gồm các lệnh một lớp truy vấn.
• Bằng DDD, bạn xác định các sự kiện miền để tách mô hình miền khỏi các chi tiết liên tục.
• Bằng DDD, bạn có một ngôn ngữ phổ biến trên mỗi ngữ cảnh giới hạn thể hiện ngữ nghĩa.
• Bạn làm tất cả những điều này để tách hoàn toàn mô hình miền khỏi thế giới bên ngoài.

Có thể ánh xạ giao diện đồng phục REST đến giao diện miền được xác định bằng lệnh và truy vấn và sự kiện miền không? (Vì vậy, mã dịch vụ REST sẽ được tạo tự động.)

Có thể ánh xạ ngữ nghĩa dữ liệu được liên kết với các ngôn ngữ phổ biến không? (Vì vậy, bạn sẽ không cần phải xác định các thuật ngữ rất giống nhau, chỉ cần tìm và sử dụng lại các từ vựng hiện có.)

Vui lòng thêm một ví dụ lập bản đồ rất đơn giản cho câu trả lời của bạn, tại sao có hoặc tại sao không!

Answer 1

Tôi không nghĩ điều này là có thể. Có một thuật ngữ mà tôi tin rằng mô tả vấn đề này, nó được gọi là ontology alignment.

Trong trường hợp này có có ít nhất 3 bản thể:

• ngôn ngữ phổ biến (UL) của mô hình miền
• ứng dụng vocab cụ thể (ASO) của dịch vụ REST
• các liên kết mở vocabs dữ liệu (Lodo) mà ứng dụng vocab cụ thể sử dụng

Vì vậy, chúng ta có ít nhất 2 sắp xếp:

• UL: alignment ASO
• ASO: alignment Lodo

vấn đề của chúng tôi là liên quan đến việc UL: alignment ASO, vì vậy chúng ta hãy nói về những bản thể học.

UL là đối tượng được định hướng, bởi vì chúng ta đang nói về DDD và mô hình miền. Vì vậy, hầu hết các đối tượng miền entities, value objects là các đối tượng thực và không phải là cấu trúc dữ liệu. Phần không hướng đối tượng của nó là các DTO như command+domainEvent, query+result và error trên giao diện của mô hình miền.

Ngược lại ASO là thủ tục nghiêm ngặt, chúng tôi thao tác các tài nguyên (cấu trúc dữ liệu) bằng cách sử dụng một tập hợp các phương pháp chuẩn (thủ tục) trên chúng.

Vì vậy, từ khía cạnh tôi, chúng tôi đang nói về 2 việc rất khác nhau và chúng tôi đã nhận các tùy chọn sau:

• làm cho ASO hơn hướng đối tượng -> RPC
• làm cho các UL ít hướng đối tượng -> thiếu máu mô hình miền

Vì vậy, từ quan điểm của tôi, chúng tôi có thể làm những điều sau đây:

• chúng ta có thể tự động ánh xạ các thực thể tới các tài nguyên và các lệnh đến các hoạt động của CRUD, ví dụ: HydraBundle thực hiện điều này với các bản ghi hoạt động (chúng ta có thể thực hiện tương tự với DDD và không có CQRS)

• chúng ta có thể ánh xạ các lệnh bằng tay phức tạp mô hình miền

  • hoạt động POST transaction {...} có thể dẫn đến một SendMoneyCommand{...}
  • hoạt động GET orders/123/total có thể dẫn đến một OrderTotalQuery{...}

• chúng tôi không thể ánh xạ các đối tượng với các nguồn lực của một mô hình miền phức tạp, bởi vì chúng ta phải xác định nguồn lực mới để mô tả một dịch vụ mới hoặc một phương pháp tổ chức mới, ví dụ

  • hoạt động POST transaction {...} có thể dẫn đến account.sendMoney(anotherAccount, ...)
  • hoạt động GET orders/123/total có thể gây ra một truy vấn SQL vào cơ sở dữ liệu đọc mà không bao giờ chạm vào một thực thể duy nhất

tôi nghĩ rằng nó không thể làm điều này loại ontology sự liên kết đặt cược ween DDD + CQRS và REST, nhưng tôi không phải là chuyên gia về chủ đề này. Những gì tôi nghĩ chúng ta có thể làm là tạo ra một ứng dụng cụ thể với các lớp tài nguyên, thuộc tính và hoạt động và ánh xạ các hoạt động tới các lệnh/truy vấn và các thuộc tính cho các thuộc tính lệnh/truy vấn.

Answer 2

Bạn đã đặt ra một số câu hỏi thú vị tại đây.

Để bắt đầu tôi không hoàn toàn đồng ý với

By DDD bạn xác định sự kiện miền để tách các mô hình miền từ chi tiết kiên trì.

Tôi nghĩ bạn có thể nhầm lẫn với DDD, ES có thể được sử dụng với DDD nhưng rất nhiều tùy chọn trong thực tế bạn nên suy nghĩ kỹ trước khi chọn nó làm cơ chế kiên trì của bạn.

Bây giờ với phần lớn câu hỏi của bạn, liệu REST và DDD có hòa thuận không nếu có?

Việc tôi thực hiện nó, vâng, họ không làm quen với nhau, tuy nhiên thông thường bạn không muốn để lộ mô hình miền của mình thông qua giao diện REST, bạn muốn xây dựng trừu tượng hóa nó và sau đó phơi bày điều đó.

Bạn có thể tham khảo câu trả lời này here để biết thêm chi tiết.

Tuy nhiên tôi không thể đề xuất đủ cuốn sách Implementing Domain-Driven Design, Chương 14 Các giao dịch ứng dụng với mối quan ngại của bạn ở mức độ công bằng.

Tôi không thể giải thích kỹ hơn sách và do đó giới thiệu bạn ở đó :)