Logic kinh doanh của Cameron có nghĩa là gì nếu không phải là tất cả các mã bên thứ 3 không phải là thứ gì?

Tôi đã nghe mọi người nói về logic kinh doanh rất nhiều trong công việc và trực tuyến, và tôi đã đọc một số câu hỏi trên trang web này về nó, nhưng thuật ngữ này vẫn không có ý nghĩa nhiều đối với tôi. Ví dụ, đây là một số câu (paraphrased) tôi thường thấy:

• "Logic kinh doanh là một phần của chương trình của bạn mã hóa các quy tắc kinh doanh thực tế." Hầu hết các định nghĩa tôi đã đọc là những hình tròn như thế này.

• "Logic kinh doanh là tất cả mọi thứ duy nhất cho ứng dụng cụ thể của bạn." Tôi không thấy điều này khác với "ứng dụng cụ thể của bạn không là gì ngoài logic kinh doanh", trừ khi chúng tôi vô tình phát minh lại một loạt các bánh xe mà chúng tôi có thể đã sử dụng phần mềm của bên thứ 3 hiện có. Do đó tiêu đề câu hỏi.

• "Cần có Lớp logic nghiệp vụ phía trên Lớp truy cập dữ liệu của bạn và bên dưới Lớp GUI của bạn." Trong mã tôi viết, người truy cập cơ sở dữ liệu phải biết dữ liệu nào họ sẽ truy cập và mã UI phải biết nhiều về nội dung hiển thị để hiển thị chính xác và không có gì thực sự phải làm ở giữa hai nơi đó ngoài việc truyền các đốm dữ liệu giữa máy khách và máy chủ. Vì vậy, những gì thực sự cần phải đi vào một lớp logic kinh doanh?

• "Logic kinh doanh nên tách biệt với logic trình bày." Hầu hết các yêu cầu tính năng chúng tôi nhận được là thay đổi logic trình bày vì lý do kinh doanh. Nếu một trong các quy tắc kinh doanh là hiển thị giá trái phiếu chính phủ Hoa Kỳ theo ký hiệu thứ 32 theo mặc định (đồng thời cung cấp UI cho người dùng để định cấu hình đó), thì logic trình bày ít nhất phải biết quy tắc này tồn tại, nếu không thực hiện đầy đủ quy tắc này. Ngoài ra, có vẻ như một phần chính của thiết kế UX đang giúp người dùng hiểu các quy tắc kinh doanh mà phần mềm của chúng tôi đang cố gắng thực hiện.

Có thể là tôi thực sự ở trong một nhóm chỉ làm logic kinh doanh và tất cả logic phi kinh doanh đang được thực hiện bởi các nhóm khác? Hay toàn bộ khái niệm "logic kinh doanh" là một thực thể riêng biệt chỉ khả thi đối với các ứng dụng hoặc kiến ​​trúc nhất định?

Để giúp đưa ra câu trả lời cụ thể: Giả sử bạn phải thực hiện lại ứng dụng Pizza của Domino. Logic kinh doanh là gì và logic phi kinh doanh của ứng dụng đó là gì? Và làm thế nào có thể đưa logic kinh doanh đặt hàng pizza đó vào "lớp" mã của riêng nó, mà không có hầu hết các thông tin về pizza chảy vào lớp truy cập và trình bày dữ liệu?

Cập nhật: Tôi đã đi đến kết luận rằng nhóm của tôi có thể đang thực hiện 90% mã UI và hầu hết - nhưng không phải tất cả - về những gì bạn gọi là logic kinh doanh đến từ các nhóm hoặc công ty khác. Về cơ bản, ứng dụng của chúng tôi là để theo dõidữ liệu tài chính và hầu hết tất cả các tính năng là cách để người dùng tùy chỉnh dữ liệu họ thấy và cách họ nhìn thấy dữ liệu đó. Không có mua hoặc bán đang diễn ra (mặc dù chúng tôi tích hợp một chút với các ứng dụng khác từ công ty của chúng tôi làm điều đó) và dữ liệu thực tế được cung cấp bởi vô số nguồn bên ngoài. Nhưng chúng tôi cho phép người dùng thực hiện những việc như gửi bản sao "màn hình" của họ cho người dùng khác, vì vậy các chi tiết về cách chúng tôi xử lý có thể đủ điều kiện là logic kinh doanh. Thực sự có một ứng dụng di động hiện đang nói chuyện với một số mã phụ trợ của chúng tôi và tôi biết chính xác phần nào trong mã frontend của chúng tôi mà tôi muốn chia sẻ với UI của chúng tôi trong một thế giới lý tưởng (về cơ bản là M trong quasi-MVC của chúng tôi) Tôi đoán đó là BLL cho chúng tôi.

Tôi chấp nhận câu trả lời của user61852 vì nó cho tôi hiểu rõ hơn về "logic kinh doanh" làm gì và không đề cập đến.

Tôi sẽ cung cấp cho bạn một số mẹo về các ứng dụng CRUD , vì tôi không có nhiều kinh nghiệm trong các trò chơi hoặc các ứng dụng chuyên sâu về đồ họa:

• Logic kinh doanh thường liên quan đến các quy tắc mà chủ sở hữu của doanh nghiệp đã học hoặc quyết định qua nhiều năm hoạt động, ví dụ như: "từ chối bất kỳ khoản tín dụng mới nào nếu khách hàng chưa thanh toán xong khoản cuối cùng" hoặc "chúng tôi không bán bữa sáng quá 11 giờ sáng " hoặc " thứ hai và thứ ba, khách hàng có thể mua hai chiếc pizza với giá bằng một " .
• Tất nhiên, lớp trình bày phải hiển thị thông báo cho biết mức giảm giá có sẵn hoặc lý do tín dụng bị từ chối, nhưng lớp đó không quyết định những điều đó, nó chỉ truyền đạt cho người dùng điều gì đó xảy ra dưới mui xe.
• Logic nghiệp vụ thường liên quan đến quy trình làm việc , ví dụ: "mục này phải được người quản lý chấp nhận trong vòng 3 ngày làm việc hoặc đưa vào giai đoạn 'yêu cầu thông tin', nếu khách hàng chưa gửi tài liệu cần thiết, thì mục đó bị từ chối" .
• Lớp trình bày thường không xử lý loại quy trình công việc đó, nó chỉ phản ánh các trạng thái của quy trình công việc.
• Ngoài ra, lớp truy cập dữ liệu thường đơn giản, bởi vì các quyết định đã được đưa ra bởi logic kinh doanh. Lớp này bị ảnh hưởng khi bạn quyết định di chuyển dữ liệu của mình từ MS SQL Server sang Oracle, ví dụ
• Đôi khi, GUI thực hiện một số xác thực để tránh các cuộc gọi đến máy chủ, nhưng đó là điều cần được thực hiện một cách thận trọng hoặc bạn có thể có nhiều logic nghiệp vụ trong lớp đó.
• Phần lớn sự nhầm lẫn của bạn có thể xuất phát từ thực tế là trong ứng dụng của bạn không có sự phân tách mối quan tâm và thực sự bạn có quá nhiều logic kinh doanh trong lớp trình bày. Việc bạn (sai) có logic nghiệp vụ trong lớp ứng dụng hoặc lớp truy cập dữ liệu của bạn không làm thay đổi thực tế rằng đó là logic kinh doanh nào.
• Những điều như hiển thị khoảng cách trong hệ thống số liệu thay vì dặm / bãi / chân không phải là trình bày logic, đó là logic kinh doanh . Lớp nghiệp vụ phải trả về dữ liệu trong các đơn vị được yêu cầu và báo cho lớp trình bày những đơn vị mà nó xử lý để hiển thị nhãn phù hợp, nhưng đó chắc chắn là mối quan tâm logic kinh doanh.
• Logic kinh doanh không nên bị ảnh hưởng bởi thực tế là bạn hiện đang sử dụng Oracle thay vì Postgres hoặc thực tế là công ty đã thay đổi logo hoặc biểu định kiểu.
• Quy tắc kinh doanh tồn tại cho dù bạn có tự động hóa nó hay không bằng cách viết một ứng dụng. Chúng có thể được thực thi ngay cả khi doanh nghiệp sử dụng giải pháp công nghệ thấp như bút và giấy.
• Nếu bạn có phiên bản di động của ứng dụng máy tính để bàn hoặc phiên bản web , mỗi phiên bản đó có một lớp trình bày khác nhau , nhưng (hy vọng) cùng một lớp doanh nghiệp.

Có vẻ như hầu hết các công việc của bạn có thể là trong lớp UI. Thay đổi định dạng hiển thị vì lý do kinh doanh, không ngụ ý bất kỳ logic kinh doanh nào. Sự thay đổi là một sự thay đổi đối với logic xem.

Có thể thay đổi định dạng ngụ ý một số logic kinh doanh có thể liên quan đến sự kiên trì của sở thích.

Duy trì định dạng cho cookie, cũng có thể được thực hiện trong lớp xem.

Tuy nhiên, điều này có thể được thực hiện theo cách MVC. (Một số mô hình triển khai chế độ xem dưới dạng MVC của chính nó có khả năng xử lý các tùy chọn.)

• Tùy chọn của người dùng có thể được lưu trữ theo mô hình (cơ sở dữ liệu / cookie).
• Bộ điều khiển sẽ phản ứng với các yêu cầu định dạng bằng cách thay đổi tùy chọn của người dùng trong mô hình.
• Chế độ xem sẽ điều chỉnh theo sở thích của người dùng. Tùy chọn có thể được yêu cầu từ mô hình, hoặc được cung cấp bởi bộ điều khiển.

Làm cho một phỏng đoán có giáo dục về ứng dụng của bạn.

• Có một mô hình chứa trái phiếu có sẵn và dữ liệu giá cho chúng.
• Có một khung nhìn cho phép người dùng thấy nhiều thứ họ có thể làm: tìm kiếm trái phiếu, hiển thị giá, so sánh sản lượng, nhận đơn đặt hàng và hiển thị kết quả mà mô hình kinh doanh trả về theo yêu cầu.

• Logic nghiệp vụ xử lý những thứ như:

  • Thực hiện tìm kiếm và cung cấp cho chế độ xem để hiển thị.
  • Tìm giá cho một trái phiếu và cung cấp cho xem để hiển thị.
  • So sánh sản lượng và cung cấp dữ liệu cho chế độ xem để hiển thị.
  • Xử lý đơn đặt hàng và lưu trữ chúng trong mô hình.

Nếu điều này được thực hiện đúng, có thể cung cấp nhiều thành phần xem mà không thay đổi mô hình hoặc logic nghiệp vụ. Ví dụ: nếu thiết kế hiện tại là một trang web, máy chủ chế độ xem mới cho ứng dụng iPhone hoặc Android sẽ sử dụng mô hình và logic nghiệp vụ hiện có. Chúng có thể giới thiệu chức năng kinh doanh mới để cung cấp thông báo đẩy khi đơn hàng được thực hiện, có thể yêu cầu thay đổi đối với nhiều lớp.

Sự cố này cho phép tách các mối quan tâm.

• Lớp dữ liệu được đại diện bởi mô hình có xu hướng tương đối ổn định.
• Tầng kinh doanh là nơi áp dụng các quyết định kinh doanh: Yêu cầu sẽ / có thể được thực hiện không? Có tất cả các dữ liệu cần thiết đã được thu được? Người dùng có được ủy quyền không? Có bất kỳ cờ đỏ trên giao dịch?
• Lớp khung nhìn có xu hướng kém ổn định hơn và có thể có nhiều hơn một. Đây là nơi giao diện của ứng dụng cư trú. Có thể hoàn toàn tái tạo một ứng dụng, mà không thay đổi các lớp khác.