Trong Thiết kế theo hướng miền, bạn có thể sử dụng thực thể miền trong giao diện người dùng của mình không?

Question

Trong nhiều dự án DDD hàng đầu, đặc biệt là kiểu MVC, tôi thấy giao diện người dùng sử dụng các đối tượng hiển thị phản chiếu thực thể miền, thay vì sử dụng trực tiếp các đối tượng miền đó. Phong cách này rõ ràng là để tách và tách mối quan tâm, và cá nhân tôi thích phong cách này.

Nhưng những gì tôi không chắc chắn, liệu đây có phải là nguyên lý nghiêm ngặt của DDD hay không, hay liệu đây có phải chỉ là cách giải thích của các nhà phát triển khác nhau về nó hay không.

Bạn có thể sử dụng các đối tượng miền của mình trực tiếp trong giao diện người dùng và vẫn đang tuân theo phương pháp DDD trong hành động đó không?

Hay thực tiễn tốt nhất của DDD là luôn sử dụng các đối tượng hiển thị?

Lưu ý: Trong khi tôi đề cập đến MVC, tôi thực sự quan tâm đến việc các đối tượng hiển thị có được sử dụng trong hầu hết các mẫu giao diện người dùng tương thích DDD trong dự án DDD hay không.

Answer 1

DDD là một cách suy nghĩ khi thiết kế phần mềm bắt đầu bằng cách tạo mô hình miền. Khi webpage đặt nó:

Thiết kế theo hướng miền không phải là công nghệ hoặc phương pháp luận. Đây là cách suy nghĩ của và một bộ ưu tiên nhằm mục đích tăng tốc các dự án phần mềm phải đối phó với các miền phức tạp.

Một điều tự nhiên sau mẫu thiết kế này là kiến ​​trúc phân lớp. Như được nói trong DDD Pattern Summaries

Phân vùng chương trình phức tạp thành LAYERS. Phát triển thiết kế trong mỗi LAYER được gắn kết và chỉ phụ thuộc vào các lớp bên dưới. Làm theo các mẫu kiến ​​trúc tiêu chuẩn để cung cấp khớp nối lỏng lẻo với các lớp ở trên. Tập trung tất cả các mã liên quan đến mô hình miền trong một lớp và cách ly nó khỏi người dùng giao diện, ứng dụng và mã cơ sở hạ tầng. Tên miền các đối tượng, miễn phí trách nhiệm của hiển thị bản thân, lưu trữ bản thân, quản lý ứng dụng tác vụ, v.v., có thể được tập trung vào thể hiện mô hình miền.Điều này cho phép mô hình phát triển thành phong phú đủ và đủ rõ ràng để nắm bắt kiến ​​thức kinh doanh thiết yếu và đặt hoạt động.

Bạn có cần phải có đối tượng hiển thị để làm điều đó không? Đó chỉ là một cách để thực hiện điều này, nhưng có thể thậm chí không phải là cách tốt nhất để cung cấp khớp nối lỏng lẻo. Ví dụ: có thể lớp xem là một tệp webbrowser và xlt để trực quan hóa các tệp xml được lớp kinh doanh phát ra? Nếu có ai có nhiều ví dụ phù hợp hơn, vui lòng thêm chúng. Quan điểm của tôi là DDD nhấn mạnh một kiến ​​trúc phân lớp, nhưng không giới hạn điều này thành một giải pháp khả thi.

Answer 2

Nếu bạn đang thực hiện mẫu MVC, bạn cần xem các đối tượng; DDD chỉ là mô hình của bạn. Điều đó không có nghĩa là bạn phải luôn sử dụng MVC; DDD có thể được xây dựng, giả sử, như một bộ mô phỏng, nơi tất cả các bạn nhìn vào là các thông điệp tường trình được phát ra. Nhưng trong MVC bạn thực sự cần có các đối tượng xem riêng biệt.

Bây giờ, hãy tự hỏi tại sao lại như vậy? Câu trả lời là chế độ xem có thể thay đổi, mặc dù mô hình kinh doanh không. Mô hình DDD nên thể hiện, theo thuật ngữ của doanh nghiệp, điều gì là cần thiết cho doanh nghiệp.

Answer 3

Trong thiết kế MVC, bạn thường sẽ có ánh xạ từ Kho lưu trữ -> Mô hình miền và sau đó từ Mô hình miền -> Xem mô hình. Mô hình Xem thường chứa các đối tượng miền mặc dù.

Answer 4

Câu trả lời là khá thẳng:

• Các đối tượng miền có thiết kế miền định hướng và phương pháp.
• Các đối tượng dạng xem có thiết kế và phương pháp định hướng/kiểm soát.

Nếu bạn có thể sử dụng đối tượng miền của mình trong chế độ xem, chúng có thể không hoàn toàn được định hướng theo miền.

Answer 5

Tôi đã không thực sự bắt đầu hiểu lý do tại sao hoặc làm thế nào bạn tách rời mô hình miền khỏi các vấn đề trình bày cho đến khi tôi bắt đầu theo dõi công việc của Greg Young và Udi Dahan (thông qua Martin Fowler).

Họ đã dạy một nguyên tắc được gọi là Command and Query Responsibility Segregation (CQRS).

Giải thích của tôi về CQRS là có hai bộ trách nhiệm có thể kéo mô hình miền theo các hướng khác nhau, dẫn đến một mô hình thực hiện công việc tầm thường của cả hai. Hai trách nhiệm là các lệnh (tức là hành vi sẽ gây ra một ghi vào cơ sở dữ liệu) và các truy vấn (tức là đọc từ cơ sở dữ liệu để lấy dữ liệu cho việc sử dụng giao diện người dùng). Một ví dụ sẽ được thêm getters và setters cho các thực thể của bạn để hỗ trợ Databinding trong giao diện người dùng. Nếu mô hình của bạn có getters và setters, nó có thể sẽ làm một công việc nghèo của mô hình thay đổi trạng thái cần phải xảy ra giao dịch hoặc đóng gói logic kinh doanh. Nó cũng sẽ không có cách nào để mô hình hóa bối cảnh kinh doanh của các thay đổi trạng thái (xem Event Sourcing).

Trong điều khoản DDD, bạn có thể nói rằng mô hình miền và mô hình trình bày thường nằm trong các bối cảnh có ranh giới riêng biệt.

Giải pháp theo quy định của CQRS là tạo một mô hình cho các lệnh và một mô hình khác cho các truy vấn. Nếu mô hình hiện tại của bạn có các phương thức để thay đổi trạng thái (tức là hành vi trong mô hình), và getters để lộ trạng thái cho giao diện người dùng cho databinding, bạn sẽ tái cấu trúc hai trách nhiệm này thành các mô hình riêng biệt cho các lệnh và truy vấn. Mô hình truy vấn sẽ không được ánh xạ tới các thực thể miền của bạn, nhưng thay vào đó trực tiếp đến cơ sở dữ liệu. Nếu cơ sở dữ liệu của bạn không nắm bắt được trạng thái dẫn xuất từ ​​mô hình miền của bạn, hãy kiểm tra một mẫu có tên là Eager Read Derivation.

Nếu hệ thống của bạn chỉ đơn giản là CRUD và không có hành vi, hãy thử một hệ thống giàn giáo có thể được tự động xây dựng tắt của schema cơ sở dữ liệu của bạn, giống như ASP.NET Dynamic Data

Answer 6

đối tượng miền là thực sự logic nội bộ bên trong của bạn lớp logic nghiệp vụ. Chúng không được tiếp xúc trực tiếp với khách hàng của bạn (lớp giao diện người dùng). Thay vào đó, hãy đóng gói việc sử dụng mô hình miền của bạn thành các dịch vụ ứng dụng. Các dịch vụ ứng dụng có thể sử dụng các DTO và/hoặc các đối tượng lệnh nhẹ để truyền dữ liệu và ý định giữa máy khách và mô hình miền.