2013-04-11 11 views
3

我想圍繞領域驅動的服務層的設計理念,包括應用程序服務和域服務。幾乎所有我遇到的例子都與使用數據庫的CRUD應用程序有關。我無法理解這些概念如何映射到圖形應用程序,例如我爲這個問題選擇的示例應用程序,即在.NET/C#中開發的Microsoft Paint的克隆。基於圖形的應用程序的域服務和應用程序服務

我看了basic concept of a service layer in DDDexpanded explanation。我所選擇的以下應用層:

基礎設施(交叉)

  • 測井

數據(文件系統)

  • 的BitmapImage,PngImage等

域名

  • 帆布,圖像,選擇,形狀,刷等

應用

演示(本地客戶端WPF)

  • 瀏覽
  • 的ViewModels

我試圖設計的一個用例是用戶在畫布上繪製矩形。 From what I've read,由於用例需要幾個域對象的合作,所以域服務DrawingService是合理的。

另一個用例是用戶加載要顯示的文件。再次,from what I've read,因爲這個用例是一個命令和一個工作流,所以應用服務FileLoadingService是有意義的。

As Martin Fowler describes,我相信Microsoft Paint足夠複雜以保證服務子系統,這裏基於主題行爲。然而,隨着應用程序的增長,服務層可能被重構成屬於域模型的分區,例如, CanvasService,SelectionService等等,那麼現在需要另一層抽象層perhaps an application facade,現在多個服務必須合作?

更新1:

的初步意見建議DDD架構是不適合的繪圖應用程序。任何建議的替代?

+4

imho繪圖應用程序不是一個非常適合DDD。它會使用別的東西。 – jgauffin 2013-04-11 14:47:02

+2

我同意。繪圖是一個很好理解和模擬的領域,沒有理由嘗試去適應DDD戰術工具。這樣做會產生摩擦;主要原因是大多數DDD工具都是針對客戶端 - 服務器體系結構,複雜的持久性方法,這些都與繪圖程序無關。 – eulerfx 2013-04-11 15:13:40

+1

大多數時候,如果你不需要域專家,你不需要DDD。 – 2013-04-11 17:20:32

回答

0

如果一個繪圖應用程序不適合DDD。它會使用別的東西

相關問題