Nơi đặt logic nghiệp vụ trong DDD

Question

Tôi đang cố gắng tìm ra cách tốt nhất để xây dựng một kiến ​​trúc dễ kiểm tra và có thể kiểm chứng. Đã trải qua một số dự án, tôi đã nhìn thấy một số kiến ​​trúc khá xấu và tôi muốn tránh những sai lầm trong tương lai trên các dự án của riêng mình.

Giả sử tôi đang xây dựng một ứng dụng ba lớp khá phức tạp và tôi muốn sử dụng DDD. Câu hỏi của tôi là, tôi nên đặt logic kinh doanh của mình ở đâu? Một số người nói rằng nó nên được đặt trong các dịch vụ (lớp dịch vụ) và điều đó có ý nghĩa. Có một số dịch vụ tuân thủ Nguyên tắc về trách nhiệm duy nhất có ý nghĩa.

Tuy nhiên, một số người cho rằng đây là mô hình chống và logic kinh doanh không nên được triển khai trong lớp dịch vụ. Tại sao điều này?

Giả sử chúng tôi có IAuthenticationService có phương thức có chữ ký bool UsernameAvailable(string username). Phương thức này sẽ thực hiện tất cả các yêu cầu logic để kiểm tra xem tên người dùng có sẵn hay không.

Vấn đề ở đây theo đám đông "đây là một phản ứng" là gì?

Answer 1

Một lớp dịch vụ trong bản thân nó không phải là một mẫu chống, nó là một nơi rất hợp lý để đưa các yếu tố nhất định của logic kinh doanh của bạn. Tuy nhiên, bạn cần phải áp dụng theo ý muốn thiết kế lớp dịch vụ, đảm bảo rằng bạn không ăn cắp logic nghiệp vụ từ mô hình miền của bạn và các đối tượng bao gồm nó.

Bằng cách thực hiện điều đó, bạn có thể kết thúc với mô hình chống mẫu thực sự, mô hình miền thiếu máu. Điều này được thảo luận chuyên sâu bởi Martin Fowler here.

Ví dụ về IAuthenticationService của bạn có lẽ không phải là tốt nhất để thảo luận vấn đề - phần lớn logic xung quanh xác thực có thể được xem như đang sống trong một dịch vụ và không thực sự liên kết với các đối tượng miền. Một ví dụ tốt hơn có thể là nếu bạn có một số loại IUserValidationService để xác thực người dùng, hoặc thậm chí tệ hơn một dịch vụ thực hiện một thứ gì đó như các lệnh xử lý - dịch vụ xác nhận sẽ loại bỏ logic ra khỏi đối tượng người dùng và dịch vụ xử lý đơn hàng đang lấy logic từ đối tượng đặt hàng của bạn, và cũng có thể từ các đối tượng đại diện cho khách hàng, thông báo giao hàng, v.v ...

Answer 2

Nếu bạn đặt tất cả logic nghiệp vụ của mình vào một lớp dịch vụ (hoàn toàn không quốc tịch). Bằng cách tách hành vi khỏi dữ liệu, bạn đang từ bỏ việc viết mã hướng đối tượng.

Điều đó không phải lúc nào cũng xấu: nó đơn giản và nếu bạn có logic nghiệp vụ đơn giản thì không có lý do gì để đầu tư vào một đối tượng chính xác theo hướng domain model.

Logic phức tạp hơn (và miền càng lớn), mã thủ tục nhanh hơn biến thành mã spaghetti: các thủ tục bắt đầu gọi nhau với các điều kiện trước và sau khác nhau (theo thứ tự không tương thích) và bắt đầu yêu cầu các đối tượng nhà nước ngày càng phát triển.

Martin Fowler's article on Anemic Domain Models có lẽ là điểm khởi đầu tốt nhất để hiểu lý do tại sao (và trong điều kiện nào) mọi người phản đối việc đặt logic nghiệp vụ trong một lớp dịch vụ.