將CRUD分解為基於任務的UI -CodeOpinion

從基於CRUD（建立，讀取，更新刪除）的UI轉移到基於任務的UI，意味著建立一個使使用者任務明確的使用者介面。任務（或動作，命令）是一種指導使用者執行鍼對給定狀態或工作流可以採取的特定動作的方法。當按操作細分時，您可以開始檢視邊界可能在哪裡，這可以幫助將實體劃分為多個邊界。

增刪改查

對於此示例，我使用的產品實體包含我們的應用程式中使用的各種屬性。

所有屬性應該是不言自明的。如果我們要建立一個基於CRUD的UI，我們將簡單地擁有一個頁面/表單，該頁面/表單允許使用者設定所有各種屬性。

當您單擊儲存按鈕時，所有資料都將傳送到伺服器，並且整個實體都將更新。

那麼CRUD有什麼問題呢？

在某些情況下，建立基於CRUD的UI可能沒有任何問題。但是，當您開始根據使用者正在更改的資料來推斷使用者的意圖時，最好是改用基於任務的UI。

在上面的基於CRUD的UI中，如果使用者將價格從$ 85更改為$ 80，然後單擊“儲存”，他們是否只是在更改價格？那是他們的意圖嗎？還是他們打算降價？您系統的其他哪些部分需要知道這種情況？

您能告知“願望清單”中包含該產品的客戶價格現在更低了嗎？

基於CRUD的UI不能捕獲使用者的意圖。這不是明確的。您需要得出使用者意圖是什麼。在基於任務的UI中，您要使使用者的操作明確。使隱式顯式。

邊界

構建基於任務的UI的第一步是瞭解實體上的哪些屬性會一起更改或相關

具有名稱和描述的紅色（頂部）框可以一起更改，也可以獨立更改。這兩個後面可能沒有太多的行為/任務，因此它們可能只是CRUD。

帶有價格，待售和免費送貨的紫色（左下）框可能用於銷售目的。

綠色（中間下部）框具有“成本”，這是來自供應商或製造商的成本。它根本與銷售價格無關。

黃色的框（右下）具有“數量”，即“倉庫中的現有數量”。它與成本或銷售價格無關。

基於任務的使用者介面

如果您使用基於CRUD的UI並將每個框分隔到其各自的邊界中，則可以開始詢問以下問題：使用者在更改這些欄位時的意圖是什麼。他們為什麼要改變它們？不同的使用者/角色可能對不同的資料有興趣。

SKU，名稱，描述可能歸目錄服務/邊界所有。本質上，這可能完全是CRUD。但是，價格可能歸銷售所有。採購將擁有成本，而現有數量將由倉庫擁有。

從使用者/角色的角度來看，當他們想要在該邊界內更改資料時，他們試圖執行哪些任務。

現在我們可以看到Sales可以增加價格或減少價格。如果我們想提高價格，我們將提供針對特定任務/命令的功能。

如果倉庫對產品進行庫存檔點，並確定貨架上的數量不如系統所說的那麼多，那麼他們將進行庫存調整。他們不僅在更新QuantityOnHand值，而且還出於特定原因顯式更改要新增到QuantityOnHand或從中刪除的數量。

邊界

我們不僅明確定義了使用者的任務/動作是什麼，而且還定義了邊界。產品的概念可以存在於多個邊界/服務中。您不需要將一個實體放在一個地方，它包含整個系統的所有資料。