Làm thế nào để tách sạch các phần khác nhau của một ứng dụng phần mềm?

Tôi đang thiết kế một ứng dụng mới liên quan đến rất nhiều logic kinh doanh.

Để tránh sự vướng víu thông thường giữa các lớp ứng dụng khác nhau thường lẻn vào các hệ thống như vậy theo thời gian, tôi muốn thực hiện tách biệt các mối quan tâm ngay từ đầu. Nói rộng ra tôi muốn tách ra:

lớp trình bày
lớp logic kinh doanh
lớp lưu trữ và lưu trữ dữ liệu

Câu hỏi tôi đang vật lộn với hầu hết là làm thế nào để thực hiện hành vi ở các cạnh một cách sạch sẽ, đặc biệt là giữa doanh nghiệp và lớp dữ liệu. Tôi đã thấy quá nhiều ứng dụng trong đó lớp dữ liệu trao các đối tượng ORM cho lớp lõi, kết hợp chặt chẽ logic logic nghiệp vụ với ORM.

Tôi có nên chuyển đổi các đối tượng ORM sang một số định dạng nối tiếp (JSON không?) Và sau đó giải tuần tự hóa nó trong lớp nghiệp vụ thành một cấu trúc dữ liệu bên trong lớp đó? Không phải là rất nhiều chi phí sao?

Làm thế nào để bạn thực hiện sạch các mối quan tâm cho các ứng dụng cỡ trung bình? Có lời khuyên nào không?

design separation-of-concerns modularization

— BM
nguồn

Đối tượng ORM là gì? Một ORM thường ánh xạ dữ liệu tới các đối tượng miền không được liên kết chặt chẽ với lớp truy cập dữ liệu, do đó không có vấn đề gì trong việc chuyển chúng sang lớp nghiệp vụ. Tất nhiên, cơ sở hạ tầng ORM không nên được chuyển qua lớp doanh nghiệp.

— JacquesB

Tôi thấy rất nhiều lớp tạo tự động ORM ánh xạ lược đồ cơ sở dữ liệu 1: 1 article.getId(), article.getTimestamp()v.v. , Những ánh xạ này dường như thường xuyên hơn không đặc trưng cho ORM được sử dụng.

— BM

Bạn có lẽ nên chuyển ORM. Bạn đang sử dụng ORM nào?

— JacquesB

Chưa quyết định ORM cho dự án này, nhưng tôi đã làm việc với một vài người: SQLAlchemy, SQLObject, Django ORM, Propel, ...

— BM

Bạn tìm thấy những gợi ý chi tiết về điều này trong phần mô tả của Bác Bob về Kiến trúc sạch . Các đoạn "vượt qua ranh giới" và "Dữ liệu nào vượt qua ranh giới" đang xử lý chính xác vấn đề của bạn.

— Doc Brown

Câu trả lời:

Luôn có một cái gì đó của một khớp nối logic giữa logic kinh doanh và cơ sở dữ liệu. Những nỗ lực của bạn nên được tập trung vào việc ngăn chặn một khớp nối vật lý .

Ví dụ: lấy quy tắc kinh doanh rất cơ bản rằng mỗi người dùng phải có một ID người dùng duy nhất. Bạn có thể thử thực thi quy tắc đó trong lớp doanh nghiệp, nhưng sẽ luôn có một số trường hợp trong đó nhiều người dùng có thể thử cùng một ID người dùng và là nơi duy nhất bạn có thể kiểm tra tính duy nhất và bảo lưu ID người dùng trong một cách nguyên tử là trong cơ sở dữ liệu.

Bây giờ, lớp nghiệp vụ không cần biết tên của bảng hoặc cột hoặc thậm chí người dùng được lưu trữ trong cơ sở dữ liệu (ví dụ, họ có thể được lưu trữ trong Active Directory thay thế cho ứng dụng mạng nội bộ). Chỉ có lớp truy cập dữ liệu nên biết điều đó. Nhưng để dành một tấn nỗ lực ngắt kết nối lược đồ khỏi các quy tắc kinh doanh có lẽ là lãng phí nỗ lực.

— John Wu
nguồn

các hướng dẫn đã xuất hiện được một thời gian

— Ewan

Đảm bảo các đối tượng Mô hình nghiệp vụ của bạn nằm trong thư viện riêng của chúng không tham chiếu bất kỳ máy khách ORM hoặc cơ sở dữ liệu nào.

Sử dụng mẫu Kho lưu trữ và chỉ các giao diện tham chiếu đến các kho lưu trữ trong mã chính của bạn.

Có một thư viện kho lưu trữ cụ thể hoàn toàn riêng biệt dành cho người chơi dữ liệu tham chiếu thư viện giao diện, thư viện mô hình nghiệp vụ và máy khách cơ sở dữ liệu.

— Ewan
nguồn