Tôi đang nghiên cứu về sạch sẽ và kết quả là tôi đang suy nghĩ lại rất nhiều về cách tôi thiết kế và viết phần mềm.
Tuy nhiên, tôi vẫn đang vật lộn với các quy tắc kinh doanh như "lưu các bản cập nhật cho một số mặt hàng, tải đầu tiên Tất cả danh sách các mặt hàng tôi có quyền xem / chỉnh sửa, v.v., xác nhận rằng mặt hàng này có trong danh sách, và rằng danh mục mặt hàng hiện không bị khóa khi sử dụng, (và các quy tắc khác, v.v.) ".. vì đó là quy tắc kinh doanh (phức tạp nhưng không điển hình) và do đó nên được xử lý trong miền ứng dụng thay vì đẩy logic nghiệp vụ vào lớp db / kiên trì.
Tuy nhiên, đối với tôi, để kiểm tra hiệu quả các điều kiện này, nó thường sẽ được xử lý tốt nhất với truy vấn db được tạo thủ công, thay vì tải tất cả dữ liệu vào miền ứng dụng ...
Nếu không tối ưu hóa sớm, cách tiếp cận được đề xuất hoặc một số bài viết của chú Bob liên quan đến câu hỏi này là gì? Hoặc anh ta sẽ nói "xác nhận trong miền cho đến khi nó trở thành một vấn đề" ??
Tôi thực sự đang vật lộn để tìm bất kỳ ví dụ / mẫu tốt cho bất cứ điều gì khác ngoài các trường hợp sử dụng cơ bản nhất.
Cập nhật:
Hi tất cả, cảm ơn đã trả lời. Tôi nên rõ ràng hơn, tôi đã viết phần mềm (chủ yếu là ứng dụng web) trong một thời gian dài và chắc chắn đã có kinh nghiệm và đồng ý với tất cả các chủ đề mà bạn mô tả chung (xác thực bởi phụ trợ, nói chung là không tin tưởng dữ liệu khách hàng Tuy nhiên, chỉ theo đuổi hiệu quả thô khi có yêu cầu, thừa nhận điểm mạnh của các công cụ db khi có sẵn, v.v.) và đã trải qua vòng đời học tập của nhà phát triển về "ném tất cả cùng nhau" để "xây dựng bộ điều khiển chất béo khổng lồ với các xu hướng mã của ứng dụng N-tiers" , và bây giờ thực sự thích và nghiên cứu phong cách trách nhiệm sạch sẽ / duy nhất, v.v., về cơ bản là kết quả của một vài dự án gần đây đã phát triển thành các quy tắc kinh doanh khá phân tán và phân tán rộng rãi khi các dự án phát triển và yêu cầu khách hàng tiếp tục được đưa ra.
Đặc biệt, tôi nhìn vào kiến trúc phong cách sạch trong bối cảnh xây dựng apis REST cho khách hàng phải đối mặt với cũng như chức năng nội bộ sử dụng, nơi có nhiều quy tắc kinh doanh có thể là nhiều phức tạp hơn về cơ bản tất cả các ví dụ mà bạn nhìn thấy trên mạng (thậm chí bởi chính những người kiến trúc Clean / Hex).
Vì vậy, tôi đoán rằng tôi đã thực sự hỏi (và không nói rõ) về việc Clean và một api REST sẽ ngồi cùng nhau như thế nào, nơi hầu hết các công cụ MVC mà bạn thấy ngày nay có trình xác nhận yêu cầu đến (ví dụ thư viện FluentValidation trong .NET), nhưng có nhiều Các quy tắc "xác thực" của tôi không quá nhiều "đây có phải là một chuỗi dưới 50 ký tự" nhưng nhiều hơn "người dùng này có thể gọi người dùng / người tương tác này thực hiện thao tác này trên bộ sưu tập dữ liệu này do một số đối tượng liên quan hiện đang bị Nhóm X khóa không cho đến cuối tháng, v.v. "... những loại xác nhận có liên quan sâu sắc trong đó rất nhiều đối tượng miền doanh nghiệp và quy tắc miền được áp dụng.
Tôi có nên chuyển các quy tắc đó thành một loại đối tượng Trình xác thực cụ thể để đi kèm với mỗi trình tương tác usecase (lấy cảm hứng từ dự án FluentValidator nhưng có liên quan đến logic kinh doanh và truy cập dữ liệu hơn), tôi có nên xử lý xác thực phần nào như Cổng không đặt các xác nhận đó vào một cổng (mà tôi nghĩ là sai), v.v.
Để tham khảo, tôi sẽ giới thiệu một số bài viết như thế này , nhưng Mattia không thảo luận nhiều về xác nhận.
Nhưng tôi đoán câu trả lời ngắn cho câu hỏi của tôi giống như câu trả lời mà tôi đã chấp nhận: "Nó không bao giờ dễ dàng, và nó phụ thuộc".