應用程序中的「業務邏輯」究竟由什麼組成？

Question

我已經聽過很多次了，我們不應該將業務邏輯與其他代碼混合在一起，或者像這樣的語句。我認爲我寫的每一個代碼（我的意思是處理步驟）由與業務需求相關的邏輯組成。

任何人都可以告訴我究竟是什麼組成的業務邏輯？它如何與其他代碼區分開來？是否有一些簡單的測試來確定什麼是業務邏輯，哪些不是？

Answer 1

用簡單的英語簡單定義你在做什麼。當你在商業上說事情時，比如說「讓那些受苦」，「偷那些錢」，「摧毀這部分地球」，你談論的是商業層面。要說清楚，讓你興奮的事情就在這裏。

當你說「在此顯示」，「不要顯示」，「使它更美麗」時，你正在談論表示層。這些讓你的設計師興奮的事情。

當你說「保存這個」，「從數據庫中獲取」，「更新」，「刪除」等事情時，你正在談論數據層。這些是告訴你永遠不惜一切代價保留的東西。

Answer 2

對於我來說，「業務邏輯」彌補了所有代表適用的問題域，以及上「什麼做的數據」決定的邏輯數據實體..

所以它應該真正由「數據傳輸」（不是訪問）和「數據操作」組成。實際上，數據訪問（數據庫中的東西）應該位於不同的層中，應該與表示代碼一樣。

Answer 3

如果它包含任何有關窗體，按鈕等等的東西，它不是業務邏輯，它是表示層。如果它包含文件或數據庫的持久性，則爲DAL。兩者之間的任何事情都是商業邏輯。事實上，任何非UI有時會被稱爲「業務邏輯」，但它應該涉及問題領域，而不是管家。

Answer 4

我不喜歡圖層的BLL + DAL名稱，它們比澄清更令人困惑。
稱之爲DataServices和DataPersistence。這將使它更容易。

服務操作，持久層CRUDs（創建，讀取，更新，刪除）

Answer 5

業務邏輯是純粹的抽象，它存在獨立於用戶面前的數據的物化/可視化，以及獨立的基礎數據的持久性。

例如，在稅收準備軟件中，業務邏輯類的一個職責是計算所欠的稅額。他們不負責顯示報告或保存和檢索報稅表。

---

@Lars，「服務」意味着某種架構。

Answer 6

說起什麼不是業務邏輯可能比較容易。數據庫或磁盤訪問不是業務邏輯。 UI不是業務邏輯。網絡通信不是業務邏輯。

對我來說，業務邏輯是描述企業如何運作的規則，而不是軟件架構如何運作。業務邏輯也有改變的趨勢。例如，這可能是一項業務要求，即每個客戶都有一個與其賬戶相關聯的信用卡。此要求可能會更改，以便客戶可以擁有多張信用卡。從理論上講，這應該只是對業務邏輯的改變，軟件的其他部分不會受到影響。

這就是理論。在現實世界中（正如您找到的那樣），業務邏輯往往會在整個軟件中傳播。在上面的例子中，您可能需要將另一個表添加到數據庫以保存額外的信用卡數據。你一定需要改變UI。

純粹主義者認爲業務邏輯應該總是完全獨立，因此甚至會反對在數據庫中具有名爲「Customers」或「Accounts」的表。 如果採取極端行動，你最終會得到一個令人難以置信的通用的，不可能維護的系統。

支持將大部分業務邏輯保持在一起而不是將其拖拽到整個系統中是絕對有力的論據，但是（與大多數理論一樣），您需要在現實世界中務實。

Answer 7

爲了簡化的東西單行...
業務邏輯將是代碼，並不依賴於/不與特定的UI /實現細節改變.. 它的一個代碼表示規則，流程等，這些定義或反映了正在建模的業務。

Answer 8

我認爲你會混淆業務邏輯與你的應用程序需求。這不是一回事。當某人解釋他/她的業務的邏輯時，它是這樣的：

「當用戶購買物品時，他必須提供送貨信息，信息用xyz規則進行驗證，之後他將收到發票並賺取點，這給y的折扣優惠x％「（對不起的例子）

當你實施這個業務規則，你必須考慮在二級要求，如信息如何呈現，它將如何以持久方式存儲，與應用程序服務器通信，用戶將如何收到發票等等。所有這些要求都不是業務邏輯的一部分，應該與其分離。這樣，當業務規則發生變化時，您可以更輕鬆地調整代碼。這是事實。

有時演示文稿會複製一些業務邏輯，主要是驗證用戶輸入。但它也必須存在於業務邏輯層中。在其他情況下，爲了解決性能問題，有必要將某些業務邏輯移至數據庫。這由Martin Fowler here進行了討論。