Tôi nên đặt logic tính toán trong một Thực thể hoặc trong Lớp nghiệp vụ?

Gần đây tôi đã phải đối mặt với một câu hỏi về việc nên đặt một phép tính đơn giản trong lớp Thực thể hay Thực thể nên thuần túy chỉ để lưu trữ dữ liệu thô và để lại các logic tính toán trong lớp nghiệp vụ.

Vì vậy, câu hỏi của tôi là liệu có hợp lý để đóng gói các tính toán đơn giản trong các thuộc tính trong một lớp thực thể không?

design-patterns

— Kata
nguồn

Câu trả lời:

Nó phụ thuộc vào loại kiến trúc bạn muốn.

Trong Thiết kế hướng tên miền, bạn sẽ tạo Mô hình miền có cả dữ liệu và chức năng.

Điều này có nghĩa là Ordermột tài sản (hoặc phương thức) sẽ trả lại tổng giá của đơn hàng dựa trên OrderLines. Họ Ordercũng sẽ có một phương pháp AddOrderItem(Product product, int amount)và Ordersẽ kiểm tra xem đã có một OrderLinesản phẩm cụ thể chưa.

Trong một mô hình như vậy, bạn cũng sẽ có các đối tượng không phải là các thực thể thực sự, như Repositoryđể truy cập dữ liệu hoặc Factoryđể tạo các thực thể. Chúng được gọi là Dịch vụ tên miền. Một lớp ứng dụng chịu trách nhiệm gọi các dịch vụ miền (ví dụ để lấy một thực thể từ cơ sở dữ liệu) và sau đó nó sẽ thực thi chức năng trên thực thể. Các Application Layernên càng mỏng càng tốt.

Đây là một bài viết hay về DDD giải thích các khái niệm này chi tiết hơn.

Bạn cũng có thể sử dụng Mô hình miền thiếu máu . Điều đó có nghĩa là các thực thể của bạn bao gồm các thuộc tính get / set và không chứa hành vi. Trong thiết kế như vậy, Lớp nghiệp vụ của bạn sẽ chứa hành vi, chẳng hạn như tính Ordergiá và kiểm tra trùng lặp OrderLines.

Có nhiều ý kiến khác nhau cho dù Mô hình miền thiếu máu là một điều xấu. Cá nhân tôi thích một mô hình miền thực sự.

Bài viết này mô tả sự khác biệt giữa Mô hình miền thiếu máu và không thiếu máu.

— Đồ trang sức
nguồn

Xin chào Wouter, cảm ơn câu trả lời và các liên kết. Tôi dường như phải đối mặt với một suy nghĩ sai lầm rằng khi sử dụng mô hình miền Thiếu máu, tất cả các logic kinh doanh (ngay cả những thứ rất đơn giản) nên được đưa vào lớp doanh nghiệp. Điều này có vẻ không hợp lý trong một số trường hợp mà logic kinh doanh thực sự chỉ phụ thuộc vào chính mô hình. Ví dụ, một thuộc tính được tính từ các thuộc tính hiện có trong mô hình. Tôi không thể tìm thấy một lý do hợp lý để đưa logic kinh doanh mà tất cả phụ thuộc vào chính mô hình vào lớp kinh doanh.

Trong một mô hình miền thiếu máu, vì chúng ta có các lớp nghiệp vụ cũng như các lớp thực thể, làm thế nào để đặt tên các lớp đúng cách để tránh bị nhầm lẫn giữa chúng? Bạn có đề nghị sử dụng hậu tố? Nếu có, bạn có thể đưa ra một ví dụ?

— Kwadz

Đối với DDD, điều gì xảy ra nếu logic tính toán giá phức tạp? Ví dụ: giá dựa trên vị trí (thuế), thông tin người dùng (chiết khấu ngày sinh, chiết khấu thành viên), phiếu giảm giá, thẻ tín dụng (chiết khấu đặc biệt của thẻ tín dụng), v.v ... Làm thế nào chúng ta có thể đặt logic như vậy trong Orderlớp?

— Sher10ck

Tổng hợp đơn đặt hàng của bạn nên chứa tất cả những thông tin cần thiết để thực hiện tính toán. Bởi vì dựa trên mô tả của bạn, đây thực sự là một phần của tổng hợp. Nhưng nếu logic thực sự phức tạp và bạn có thể cần phải thay đổi nó, thì tôi sẽ chuyển máy tính dưới dạng đối tượng cho hàm tạo thực thể và để thực thể sử dụng máy tính bên trong để đặt giá.

— Burzum

Thiếu máu ... miền nghèo nàn nghe như thể nó đang mắc một loại bệnh nào đó. Bạn có muốn được điều khiển không?! Vâng!

— Matt Jenkins

Vâng, hầu hết các đối tượng kinh doanh và thực thể gần như giống nhau, hầu hết thời gian. Ví dụ: nếu bạn có một lớp sản phẩm và bạn muốn trưng ra một thuộc tính lấy một số thuộc tính hiện có trong lớp sản phẩm và thực hiện một số tính toán và sau đó phơi bày nó. Nó tốt trong thuật ngữ đó, logic của việc tạo thuộc tính đó vẫn thuộc về lớp.

Bây giờ, câu hỏi có thể đến, nơi phù hợp với lớp lớp kinh doanh của bạn. Tôi thích sử dụng lớp lớp kinh doanh có một số logic để giải quyết vấn đề kinh doanh. Ví dụ: trong ví dụ về Sản phẩm của bạn, một vấn đề kinh doanh có thể là tính tiền bằng cách sử dụng nhà cung cấp bên thứ ba như paypal.

Một điều quan trọng cần nhớ là một Thực thể sẽ luôn có một danh tính nhưng một đối tượng kinh doanh là thực thể không có nhận dạng. Ví dụ sản phẩm là một thực thể nhưng tiền sẽ không có danh tính. 1000 trường hợp tiền khác nhau sẽ giống nhau.

Đúng. Nếu logic nghiệp vụ của thuộc tính tất cả phụ thuộc vào các thuộc tính hiện có trên cùng một mô hình, sẽ tốt hơn nếu chỉ thêm thuộc tính trong mô hình. Điều này sẽ giúp mất đi cặp vợ chồng không cần thiết với lớp nghiệp vụ cho các thuộc tính được tính toán.