控制器可以充當DDD中的應用程序服務層嗎？

在ASP.NET MVC世界中，控制器可以充當應用程序層，調用我的域對象和服務來完成工作（假設控制器只是嚴格地調用域並且什麼都不做）。在特定情況下，我正在處理的應用程序流邏輯非常少，因此我正在考慮取消應用程序層並直接從控制器中調用域。控制器可以充當DDD中的應用程序服務層嗎？

這是一個公平的方法嗎？

來源

2017-01-04 Karthik Balasubramanian

只要你瞭解你的設計的含義，就沒有關於你可以做什麼和不可以做什麼的明確規則。它總是歸結爲成本 - 收益的權衡。在這種情況下，簡單性會損失靈活性。例如。如果你有多個用戶界面，該怎麼辦？如果外部系統必須與您的應用程序進行交互會怎樣我通常更喜歡立即添加額外的間接層，因爲它不是那麼好，並且可以爲您節省大量的重構。 – plalx

人們過於專注於這些設計模式。他們是模式，因爲他們解決的問題非常普遍，很多人一次又一次地做同樣的事情。但是，並非每個應用程序都需要每種模式根據應用程序的需要設計應用程序，並停止擔心是否檢查設計模式清單中的所有框。 –

@plalx：現在添加額外的間接層現在看起來對我來說太過矯枉過正，但我完全理解你的情況。我們很樂意知道引入另一層的成本會帶來成本。 –

作爲您的DDD應用程序層處理您的MVC控制器會出現一些負面情況。

最大的問題是您的應用程序層（關於DDD）是您爲域/業務流程建模的關鍵位置之一。例如，您可能會在應用服務都稱爲一個方法：

PayrollService.CalculatePayslips();

這可能包括，檢查當前在職職工域服務或外部系統，它可能然後需要查詢其他域的服務或外部系統缺勤，退休金扣除等。然後需要調用域服務（或實體）來進行計算。

在MVC控制器中捕獲像這樣的域/業務邏輯會導致架構問題，如果您想觸發系統中其他地方計算工資單的任務。此外，如果您曾想將此過程作爲Web服務公開，或者甚至是從另一個MVC控制器公開，那麼您將有參考文件穿過或進入您的表示層。像這樣的解決方案「可能有用」，但它們將有助於您的應用程序變成意大利麪條代碼或泥漿大球（在建築意義上都是代碼氣味）。您有可能導致循環引用和高度耦合的代碼，這會增加未來的維護成本（包括時間，金錢，開發人員的理智等）。

在一天結束時，軟件開發是一個折衷的遊戲。建築問題成爲更大的問題，您的應用程序越來越大。對於很多非常小的CRUD應用程序，架構問題可能可以忽略不計。 DDD的關鍵目標之一是處理難度複雜度，因此可以認爲，大多數DDD項目應具有足夠的複雜性來關注良好的企業架構原則。

來源

2017-01-05 09:00:24

我聽到你的關注，但是我是YAGNI的忠實粉絲，目前據我所知，我的控制器不需要應用程序邏輯。在我看來，創建一個應用程序層僅僅是因爲我可能需要它在功能上，或者因爲這是正確的做法，並不適合我。但是我很欣賞你的觀點，它確實重申了對應用服務的需求（我們需要它們） –

公平不夠，架構決策取決於很多事情，它總是一種平衡行爲。如果它是你自己的應用程序（只是你開發它），它的體積很小，不會增長（或者它的壽命很短），並且沒有其他開發人員需要維護它，那麼使事情變得更復雜可能沒有任何好處比他們需要的要多。 –

還有單元測試需要考慮。單元測試控制器通常比一套類庫方法更難。再次，如果你只是在試驗，編寫一個小應用程序等，你可能會發現單元測試你的代碼沒有任何好處。 –

-2

我不會這樣做。

爲應用程序服務創建單獨的類然後從控制器調用它的工作量很小。當您構建應用程序時，成本也僅限於此。

但是，由於業務層和表示層之間的高度耦合，一旦開始維護應用程序，您必須付出的代價要高得多。

當您在應用程序中確保separate different concerns時，測試，重用，重構等等要低得多。

來源

2017-01-05 10:37:09 jgauffin

我想你在這裏的意思是你的業務邏輯是使用域模型模式實現的。在這種情況下，你的應用層應該非常簡單，根據定義，它不應該託管任何業務邏輯。所有的業務邏輯應該駐留在領域層;在應用程序層的方法應類似於下面的步驟：的總

負載情況下執行動作
堅持了更新的聚合
返回響應用戶

如果是這樣的所有你在應用層做的事情，我沒有理由不把它放在控制器中。

另一方面，如果你的領域模型是貧血的，並且你在應用層中有業務邏輯，那麼我寧願引入一個單獨的層。

來源

2017-01-10 14:12:09 Vladikk

控制器可以充當DDD中的應用程序服務層嗎？

回答

相關問題