我們有一個網站，在這個網站上輸入交易並通過工作流。我們將遵循標準的BLL（業務邏輯層），DTO（數據傳輸對象），DAL（數據訪問層）等，以實現分層應用。我們需要將所有事情分離出來，因爲一些事務將跨越具有不同業務邏輯的多個應用程序。具有網站和後端交易處理器的n層設計
我們也有一個後端處理器。它在工作流程完成後處理我們的交易。它適用於各種第三方系統，其中一些系統不穩定，或者它們的接口不穩定，然後報告交易狀態。每個網站都有自己的後端處理器版本。
現在的問題，與N層，他們建議爲每個應用程序的新BLL。通過上述應用程序的佈局，可以認爲後端處理器和網站是一個一致行動的應用程序，或者是具有不同業務邏輯的兩個應用程序。什麼是處理這個問題的理想方式？有沒有像一個系統，或兩個？
我在過去幾年學習MVC時遇到的一件事是我稱之爲應用程序邏輯和領域邏輯之間的區別。我不再喜歡商業邏輯這個術語，因爲它有太多的包袱，它們來自所有相互矛盾的理論和實踐，這些術語過於鬆散。
域邏輯是「傳統的」業務邏輯，事情應該如何行動，他們需要什麼（驗證）等等。應用程序邏輯是特定於您的域的特定呈現的任何內容，當用戶單擊時這個提交按鈕在你的網絡應用程序，然後他們被引導到這裏的網頁在這裏（請注意，這有什麼與WinForms應用程序或後臺處理器如何工作）。應用程序邏輯應該存在於應用程序中域邏輯應該存在於BLL中，並且可以在可能使用您的通用「業務邏輯」的不同應用程序中重複使用。
一種普遍的答案，但我希望有所幫助。
做到這一點的「理想」方式取決於手頭的項目和系統的各種要求。
我的默認設計是讓它充當一個應用程序。但是如果有更多的重量級過程發生，我喜歡創建一個批處理過程，其中請求作業的參數被存儲並通過單獨的過程執行。
如果您很好地區分了您的擔憂，那麼我認爲您可以將它們視爲具有單個業務邏輯層的同一個應用程序，但沒有必要兩次編寫相同的代碼。技巧將迫使網站的用戶界面部分與BLL庫中的業務邏輯之間的關注分離。
性能也將成爲問題，您必須確保您的批處理不會阻止您的網站執行由於您的資源而需要執行的任務。這可能是讓它們更加分離的一個參數，但是因爲它們很可能共享一個數據庫（或者其他基於文件的資源），所以無論如何這都可能是個問題。
我會保持一個通用的業務邏輯庫編程爲接口和完全分開您的其他問題。
您可能會考慮劃分功能以反映利益相關者的組織。通常，如果您有兩個不同的組織組，則開發和管理要求更容易管理，如果功能類似分區。反之亦然。
我們大多數人都沒有花太多時間編寫探索硬件和軟件功能外部邊界的應用程序。