Có thể trả lại mô hình miền từ REST api qua ứng dụng DDD không?

Question

Nếu bạn có một lớp REST ở trên cùng của ứng dụng DDD cho CRUD, bạn có để lớp REST nhổ ra mô hình miền (về mặt dữ liệu) (nói cho GET) không?

Answer 1

Nói chung, bạn muốn có thể thay đổi đối tượng miền của mình (ví dụ: khi bạn tìm hiểu điều gì đó mới về miền) mà không phải thay đổi giao diện/API công khai cho hệ thống của mình. Điều tương tự theo cách khác xung quanh: nếu thay đổi là bắt buộc đối với giao diện công khai, bạn không muốn phải thay đổi mô hình miền của mình.

Vì vậy, từ quan điểm này, tôi sẽ không bao giờ phơi bày các đối tượng miền của mình như trên một giao diện công khai. Thay vào đó, tôi sẽ tạo các đối tượng truyền dữ liệu (DTO) là một phần của giao diện công khai. Bằng cách này, những thay đổi đối với miền của tôi và api công khai có thể thay đổi độc lập.

Answer 2

Bạn không nên để lộ mô hình DDD. Điều này là hoàn toàn chính xác, bởi vì một lối vào SOA không nên trưng ra các chi tiết thực hiện cho các khách hàng. Người dùng của bạn nên phụ thuộc vào một chức năng nghiệp vụ, không phải là một chi tiết triển khai… Nhưng điều này giả định một thiết kế tốt đẹp của một số, có thể không đồng nhất, các ứng dụng hợp nhất thành một bus SOA.

Tôi muốn thêm vào câu trả lời vì đề cập đến giao diện CRUD khiến tôi nghĩ rằng đây có thể là trường hợp lạm dụng SOA, trong đó các nguyên tắc SOA được sử dụng để dán các lớp của ứng dụng thay vì mạng ứng dụng . SOA có nghĩa là một cách để doanh nghiệp truyền đạt các hệ thống của nó, nó không phải là một cách để thực hiện MVC! Vì vậy, đơn giản nhưng rất hiểu lầm. Ví dụ, chỉ vì GUI giao diện người dùng của bạn sử dụng các dịch vụ để truy cập vào backend mà bạn không có một "ứng dụng SOA" ... điều đó có nghĩa là gì.

Nếu đây là trường hợp SOA được sử dụng để dán lớp, vui lòng sửa đổi thiết kế của bạn và sử dụng kiến ​​trúc thiết kế thích hợp cho mức trừu tượng đó. Nếu không, bạn sẽ giải thích sai các khuyến nghị được tìm thấy ở đây về việc không lộ mô hình DDD và không sử dụng CRUDY, và chắc chắn bạn sẽ tạo ra một mô hình miền riêng cho giao diện dịch vụ, sau đó bạn sẽ phải ánh xạ tới DDD. rằng bạn sẽ cần phải sử dụng dozer và những thứ tương tự như vậy để lập bản đồ cùng một tên với các tên khác nhau, v.v ... cho đến khi chúng tôi kết thúc với một mớ hỗn độn không thể bảo trì…

.. hãy cẩn thận.

-Alex

Redzedi rất đúng mà chúng ta cần làm rõ ....

Giống như tất cả mọi thứ, điều này là khá phức tạp hơn để làm hơn là nói. Việc tuần tự hóa một mô hình miền phức tạp có thể quá khó khăn đến nỗi bạn có thể kết thúc hoặc không đưa bất kỳ logic nào vào miền, mô hình thiếu mô hình thiếu máu (http://martinfowler.com/bliki/AnemicDomainModel.html) hoặc có một mô hình thiếu máu riêng biệt cho kiên trì, tức là DTO.

Tôi không biết điều gì là tồi tệ nhất, nhưng cả hai tùy chọn đều xấu. Bạn nên đặt logic mà đi vào mô hình trong mô hình và bạn sẽ có thể serialize trực tiếp ở khắp mọi nơi.

Trong kinh nghiệm sử dụng mô hình miền trong nhiều năm, tôi tin rằng điều tốt nhất là một điểm ở giữa. Vâng, như Fowler và Evans, các đối tượng kinh doanh phải mang logic, nhưng không phải tất cả (http://codebetter.com/gregyoung/2009/07/15/the-anemic-domain-model-pattern/) một chút thiếu máu với lớp dịch vụ tốt đẹp là tốt nhất.

Ví dụ: hóa đơn nên biết về các mục của nó và có quy trình tính tổng số của nó, tùy thuộc vào các mục. Nhưng mục của hóa đơn không cần biết về lập hóa đơn.Vì vậy, điều gì sẽ xảy ra khi một mục thay đổi về chi phí, nên nó có một con trỏ trở lại hóa đơn của cha như một tham chiếu vòng tròn và gọi thủ tục tính toán tổng của hóa đơn?

Tôi tin là không. Tôi nghĩ rằng đó là nhiệm vụ cho lớp dịch vụ trước tiên phải nhận sự kiện và sau đó dàn xếp quy trình, với việc phải ghép nối tất cả các đối tượng kinh doanh với nhau để thực hiện và vi phạm các quy tắc tương tác kinh doanh, đó là mô hình miền.

-Alex