業務層模塊的分離

Question

我們的新項目剛剛開始，我們遇到了與其架構相關的問題。

我們有一個3層arhitecture：

1. WebUI中
2. 業務
3. DataRepositories

每一層都有參考，以它下面的層。通信與我們所說的entities和business objects（BO）做如下：

DataRepositories <--entities--> Business <--BO--> WebUI 

<--X-->使用X類型

的對象，所以，我們有例如UserEntity爲實體User爲BO通信手段。另一種類型是門票，它又有TicketEntity和Ticket。

目前，我們必須通過具有其中明確界定，並不會與其他的片像Tickets互動DataRepositories，商務和WebUI類似Accounts爲用戶層的一些獨特的垂直切片。

現在的問題是，一張票有一個買家是一個用戶，我們不知道我們的架構中應該連接票和用戶的位置。業務組件是否應該在它們之間進行交互，或者數據層應該將用戶映射到票據？

更具體地說，我們有一個創建票據的方法，該票據駐留在Business中並從WebUI調用。它將票據和「用戶」的細節作爲參數，我們不知道它是否應該是類型用戶的對象或只是用戶名/ ID。如果我們在調用CreateTicket之前傳遞演示文稿應該得到的用戶對象。但是，如果webui傳遞了該id，那麼業務層應解析用戶對象，這將需要添加對Tickets（Business）中的用戶業務組件的引用。

Answer 1

就我個人而言，我討厭這樣的平行層次結構。你已經創建了你要調用的實體，這些實體應該有一些與它們相關的行爲，還有一個應該是不可變的，沒有任何行爲的並行層次的業務對象。

我會放棄業務對象。我懷疑他們沒有提供任何可以引用的價值，除了不變性和別人對「建築純度」的概念。

我也不喜歡實體和存儲庫之間的箭頭方向。我想讓知識庫知道實體，但不是相反。爲什麼實體應該知道或關心它是否持續？業務邏輯和行爲應該保持不變。

我會讓視圖層與服務交互。這些是UI不可知的，但它們包含了所有的業務邏輯來滿足用例。如果你扔掉你的用戶界面 - 而且你將每隔幾年 - 只要業務出現問題，你的服務就會一直存在。

數據層應負責其自己的參照完整性。如果票證需要加入以查找其用戶，則必須將其存儲在數據層中。當持久層爲用戶查詢時，它也將獲得屬於該用戶的票據並返回對象中的一對一關係。用戶將擁有一個List或一組Ticket實例。所有這些都應該在服務層完成。該服務將協調執行用例所需的持久性，業務對象和其他服務。