代碼

Question

定義業務規則的同胞程序員告訴我，我不應該把業務規則在JSP中。這真讓我困惑。

我真的很難理解這一點。我的意思是我不知道如何識別代碼中的哪一個是業務規則。

問題：

1. 真正是一個業務規則（我知道我可以在谷歌搜索這個，但你可以給我一個簡單的例子嗎？）
2. 我怎樣才能識別業務規則代碼（一個例子會很好）

Answer 1

業務規則只是一個編程邏輯，用於處理從數據庫中提取的數據。

業務規則不需要使用JSP實現。它應該使用Java編程邏輯創建，然後使用JSP來顯示數據。

Answer 2

業務規則是商業運營中用來指導行爲，形狀判斷和決策的標準。

我看到的是大部分的時間，不同類型的邏輯之間的混亂，他們都錯誤地稱爲業務規則。有許多原因不應將業務規則實施到您的源代碼中。通常，您的應用程序應該處理不同類型的邏輯：應用程序邏輯和業務規則。當您將這些彼此分開時，您允許業務規則獨立更新，而商業人士不需要更改應用程序代碼。例如，當稅率發生變化時，企業可以更新稅收規則，而無需詢問IT團隊（開發人員）。

所以你的問題，如果你仍然保持了業務的規則在JSP代碼，然後還有依賴於開發人員（IT），所以這不是從我剛纔提到的很多有益。但是，如果在代碼中以更好的方式進行構造，在項目的長期運行中將會有所幫助，因此開發人員可以更輕鬆地進行更新。

如果你想從你的源代碼完全提取出來，並讓他們來管理你的源（JSP）的側面，你需要一個業務規則管理系統（BRMS）。 BRMS的一個組件是Business Rule Engine (BRE)，它允許您執行business rules that are modelled in different forms。 當我們談論BRMS時，它不僅僅是它的執行（BRE）方面，還包括其他功能，如標準建模語言和編寫，調試，測試，版本控制，作爲服務部署和託管（REST），安全以及權限控制等......因此BRMS解決方案應涵蓋業務規則的整個生命週期。

關於以查明他們在你的代碼，恕我直言，在現有的應用程序，這是不容易識別和提取業務規則出來。這實際上取決於應用程序域的複雜性以及寫入的程度。選擇一個特定的場景，與您的學士學位坐在一起，定義實施場景的業務需求和要求，檢查邏輯是應用邏輯還是業務邏輯。 Here is an example of how business rule can be separated from source code。

Answer 3

像編程的東西，開始作爲一個明智的方針已經變異成一個不明確的規則和學究擊中無辜的程序員用棍子其他東西。

首先，沒有人會同意業務邏輯是什麼。在規模的一端，你有像@Arash這樣的人，他們認爲商業規則是商業規定的並且在他們的控制之下，例如銷售稅的確切稅率。另一方面，有些人認爲任何邏輯都像檢查sql返回碼那樣符合業務邏輯。如果你正在爲慈善醫院實施一個系統，那麼根本就沒有任何「商業」規則。

爲了簡單和清晰起見，我敦促人們堅持以下定義。 「由系統的請求者/客戶指定的規則」，所以當你的項目發起人說「像這樣計算銷售稅」時，其業務規則的一切都是實現細節。

其次，在大多數情況下，保持演示文件（如格式化屏幕，填充下拉等）與提取數據和計算數據是分開的，但並不總是那麼簡單。如果有一條業務規則「不要讓客戶看到銷售佣金數字」呢？您現在必須以不同的方式格式化屏幕，如果有客戶在場，這是一種在「演示邏輯」中最容易實現的規則。或者，「使用我的交易者理解的彭博色彩配色方案」，您在這個「商業邏輯」後端實現了「綠色升起，紅色降落，白色未改變」，或者您可以使用一些簡單易用的代碼瞭解「演示邏輯」中的代碼。

所以除非你有一個很好的理由來保持你的JSP代碼簡單並且只關心格式和表示。但是，如果有充足的理由將邏輯放在那裏，那麼就去做吧。一個簡單的竅門就是問自己：「將它作爲一個只有語音的呼叫中心應用程序是多麼容易」