Trong thiết kế được định hướng theo miền, nơi bạn sẽ mô hình miền không thiếu máu, làm thế nào để bạn quyết định những gì cần thực hiện trong các đối tượng miền của bạn so với các phương pháp hướng dịch vụ?Điều gì xảy ra trong các đối tượng mô hình miền của bạn và những gì diễn ra trong các dịch vụ của bạn?
EDIT: Tôi hỏi này một cách khác nhau với một ví dụ và có câu trả lời tốt hơn nhiều here
Ý tưởng của DDD là mô hình miền chứa dữ liệu của bạn và hầu hết các logic kinh doanh. Các dịch vụ thường đối phó với sự kiên trì của các cấu trúc này.
Sau đó, có tất cả những trường hợp ở giữa đó quy trình nghiệp vụ bao gồm nhiều bước luôn thay đổi/sửa đổi đối tượng miền. Bạn thường sử dụng dịch vụ để nhận ra một số quy trình. Vì vậy, thông thường bạn đang cập nhật các đối tượng miền với kết quả từ các dịch vụ. Bạn không bao giờ cho phép triển khai đối tượng miền gọi dịch vụ của chính họ!
Vì vậy, nó khá phổ biến để xem mã như thế này:
if (order.isValidForPurchase() && orderValidatorService.isValidOrder(order))
orderService.order(order)
Đơn giản bởi vì các bộ phận của sự thật được biết đến đối tượng theo thứ tự, và một số đòi hỏi dữ liệu bên ngoài biết đến orderValidatorService. Có thể cho rằng hai dòng mã này cũng có thể nằm trong phương thức orderService.order.
Tôi nghĩ rằng luôn luôn đáng giá để điều tra có bao nhiêu đối tượng miền tồn tại trong các quá trình này, đôi khi rất nhiều có thể đạt được bằng cách tạo ra nhiều khái niệm hơn ban đầu bạn nghĩ. Nó thực sự là giao điểm của các trạng thái quy trình nghiệp vụ và các mô hình đối tượng. Thường thì các mô hình DDD có xu hướng cố gắng nắm bắt miền từ một khung nhìn quá cấu trúc, IMO bỏ qua các quá trình lõi một chút quá nhiều. Vì vậy, nếu bạn quá cấu trúc, tôi nghĩ bạn tạo một đối tượng Order. Nếu bạn thêm quy trình, bạn có thể tạo ShoppingCartOrder, UnshippedOrder, ShippedOrder, BilledOrder và HistoricalOrder. Điều này cũng làm cho việc tích hợp dịch vụ của bạn đơn giản hơn đôi khi.