Mô hình miền không an toàn so với Mô hình miền trong thiết kế được điều khiển theo miền đơn giản

Question

Gần đây, tôi đã đọc một bài đăng trên "The Anemic Domain Model Pattern". Khi tôi đọc qua điều này, tôi thấy rằng mô tả Mô hình Miền Anemic được áp dụng cho nhiều dự án mà tôi đã làm việc và xây dựng. Tôi chưa bao giờ nghĩ đây là một quyết định thiết kế tồi tệ vì nó cảm thấy rất tự nhiên. Tôi nghĩ rằng trong trường hợp domain model là trọng lượng nhẹ và không quá phức tạp, thì biệt danh Anemic Domain Model phù hợp khá tốt. Tại sao thêm độ phức tạp vào mô hình tên miền mà nó không cần phải chỉ để tiêu đề của "Mô hình miền không an toàn" không mô tả đúng mã của bạn?

Câu hỏi: Tại thời điểm nào, việc thêm nhiều phức tạp mã vào lớp dịch vụ/ứng dụng của bạn trở nên chính xác để thay thế sự phức tạp của đối tượng thực thể? Tôi là tất cả để có một "Tổng" tài sản trên một thực thể, nơi nó nội bộ có thể tìm ra giá trị cho Tổng số. Tôi không làm cho Entity giao tiếp trực tiếp với các widget khác để xác định kết quả của một trong các thuộc tính của nó. Vì vậy, khái niệm về một mô hình miền thiếu máu là một mô hình chống hoặc phân tách mối quan tâm tốt? Tiêu đề Anemic Domain Model luôn là một điều xấu?

Chỉ cần tò mò suy nghĩ của người khác về kiểu thiết kế (chống) này.

Answer 1

Câu hỏi quan trọng là yêu cầu tại sao là mô hình miền thiếu máu?

• Gần như không có logic nghiệp vụ, như trong một ứng dụng chủ yếu là tập hợp CRUD screens?
• Kiến trúc hướng dịch vụ trong đó 'đối tượng tên miền' thực tế là cấu trúc đơn giản data transfer objects?
• Cân nhắc chính trị hoặc thực dụng như quyền sở hữu mã hoặc tương thích về phía trước/phía sau làm cản trở việc tái cấu trúc quá mức?
• Áp dụng thiết kế thủ tục/quan hệ bằng ngôn ngữ hướng đối tượng khác?

Trong mọi trường hợp, nếu tôi được chọn một quy tắc đơn giản của ngón tay cái cho ranh giới giữa mô hình miền logic và logic dịch vụ, nó sẽ là tương tác với các đối tượng có liên quan là tốt trong miền, trong khi truy cập vào "bên ngoài thế giới "(giao diện người dùng, dịch vụ web, v.v.) có thể không thuộc về mô hình miền.

Answer 2

Nếu miền có trọng lượng nhẹ (đọc: không phức tạp), cách tiếp cận được khuyến nghị là sử dụng các đối tượng kiểu ActiveRecord đơn giản trong lớp miền lõi của bạn. Thông thường một ánh xạ một-một giữa các bảng DB và các đối tượng miền của bạn và không có nhiều "logic" ở đây. Ứng dụng của bạn chỉ là xáo trộn các bản ghi giữa cơ sở dữ liệu và giao diện người dùng của bạn và cho phép các hoạt động CRUD đơn giản. Đối với các tên miền phức tạp, bạn sẽ xây dựng một mô hình miền chính nơi một số đối tượng kết thúc lập bản đồ với các bảng DB và một số có thể không và đại diện cho các khái niệm khác trong miền của bạn ngoài dữ liệu đơn giản. Logic cho ứng dụng phải ở bên trong các đối tượng khi thích hợp hoặc trong các đối tượng Service nếu nó đòi hỏi sự phối hợp giữa nhiều đối tượng miền.

Mô hình chống mô hình miền bất thường áp dụng khi bạn có miền phức tạp nhưng thay vì đặt logic một cách thích hợp vào đối tượng miền và logic trong dịch vụ, bạn đặt ALL (hoặc gần như tất cả) logic bên ngoài vào lõi của bạn đối tượng miền.

Sự khác biệt chính ở đây là nơi bạn đặt logic. Nếu bạn không có nhiều, rõ ràng các đối tượng miền sẽ trông giống như không có gì hơn là các thùng chứa dữ liệu đơn giản. Nếu bạn có logic phức tạp, không chỉ kéo nó ra khỏi tất cả các đối tượng miền mà là tách riêng nó một cách thích hợp giữa các đối tượng miền lõi và các dịch vụ miền.

Answer 3

G'day!

Nếu bạn đặt logic bên ngoài đối tượng miền, bạn mất một trong các khái niệm OO chính hoàn toàn: đóng gói (hoặc ẩn dữ liệu).

AOP làm cho nó lên đến một mức độ nhất định, nhưng sau khi tất cả, một trong những concets chính của định hướng đối tượng đã biến mất.

Kính trọng, Stefan