Mặc dù đã nghiên cứu Domain Driven Design
trong một thời gian dài hiện nay vẫn còn một số khái niệm cơ bản mà tôi chỉ tìm ra.Gặp khó khăn khi đưa logic thực tế vào lớp miền DDD
Dường như mỗi khi tôi cố gắng thiết kế một giàu domain layer
, tôi vẫn cần rất nhiều Domain Services
hoặc một dày Application Layer
, và tôi kết thúc với một loạt các đơn vị miền gần như thiếu máu không có logic thực trong họ, ngoài từ "GetTotalAmount" và tương tự. Vấn đề chính là các thực thể không nhận thức được các công cụ bên ngoài, và thực hành không tốt là đưa bất cứ thứ gì vào thực thể.
Hãy để tôi đưa ra một số ví dụ:
1. Người dùng đăng ký một dịch vụ. Người dùng được lưu giữ trong cơ sở dữ liệu, một tệp được tạo và lưu (cần thiết cho tài khoản người dùng) và một email xác nhận được gửi đi.
Ví dụ với email xác nhận đã được thảo luận rất nhiều trong các chủ đề khác, nhưng không có kết luận thực sự. Một số gợi ý đặt logic vào một số application service
nhận được EmailService
và FileService
được tiêm từ infrastructure layer
. Nhưng sau đó tôi sẽ có logic kinh doanh bên ngoài miền, phải không? Những người khác khuyên bạn nên tạo một domain service
mà được các infrastructure services
tiêm - nhưng trong trường hợp đó tôi sẽ cần phải có các giao diện của infrastructure services
bên trong domain layer
(IEmailService
và IFileService
) mà không nhìn quá tốt hoặc (vì domain layer
không thể tham khảo các infrastructure layer
) . Và những người khác đề xuất triển khai Udi Dahan's Domain Events và sau đó đăng ký dịch vụ EmailService và FileService với các sự kiện đó. Nhưng điều đó có vẻ giống như việc thực hiện rất lỏng lẻo - và điều gì sẽ xảy ra nếu các dịch vụ thất bại? Xin vui lòng cho tôi biết những gì bạn nghĩ là giải pháp đúng ở đây.
2. Bài hát được mua từ cửa hàng nhạc kỹ thuật số. Giỏ hàng đã được dọn sạch. Giao dịch mua được duy trì. Dịch vụ thanh toán được gọi. Một email xác nhận được gửi đi.
Ok, điều này có thể liên quan đến ví dụ đầu tiên. Câu hỏi đặt ra ở đây là ai chịu trách nhiệm dàn xếp giao dịch này? Tất nhiên tôi có thể đặt tất cả mọi thứ trong bộ điều khiển MVC với các dịch vụ tiêm. Nhưng nếu tôi muốn DDD thực thì tất cả logic nghiệp vụ phải nằm trong miền. Nhưng thực thể nào nên có phương thức "Mua"? Song.Purchase()
? Order.Purchase()
? OrderProcessor.Purchase()
(dịch vụ tên miền)? ShoppingCartService.Purchase()
(dịch vụ ứng dụng?)
Đây là trường hợp tôi nghĩ rất khó để sử dụng logic nghiệp vụ thực trong các thực thể miền. Nếu thực hành không tốt để tiêm bất cứ thứ gì vào thực thể, làm sao họ có thể làm những thứ khác hơn là kiểm tra trạng thái của chính nó (và trạng thái tổng hợp của nó)?
Tôi hy vọng những ví dụ này đủ rõ ràng để hiển thị các vấn đề tôi đang xử lý.
DDD đề xuất thực hiện các mục 'File' và' Email'.Cơ sở hạ tầng chịu trách nhiệm thực sự tạo một tệp và thực sự gửi email khi các thực thể tương ứng xuất hiện trong Lớp Miền. – Lightman