天天看點
傳回

abp加DDD開發：低耦合、可複用、可擴充的【工單】業務子產品-簡介和內建

abp加DDD開發：低耦合、可複用、可擴充的【工單】業務子產品-簡介和內建

前言

很多場景【單體+子產品化】比微服務更合适，開發難度低、代碼可複用性強、可擴充性強。子產品化開發有些難點，子產品啟動與解除安裝、子產品之間的依賴和通訊。asp.net core abp為我們提供了子產品化開發能力及其它基礎功能。基于abp（一代6.3）結合DDD已基本開發好一個【工單管理子產品】，本篇做個基本介紹并說明如何內建此子產品。

資源

視訊講解：https://www.bilibili.com/video/BV1ky4y1b79u/

線上demo：http://web1.cqyuzuji.com:9000/  賬号：admin 密碼：123qwe

後端源碼：https://gitee.com/bxjg1987_admin/abp

前端源碼：https://gitee.com/bxjg1987_admin/front

必備知識

熟悉asp.net core和abp（注意是老版本，非vNext，但也很容易遷移到vNext上）

術語

下文會提供到一些概念，了解這個黑重要。

abp子產品：這個不解釋了，是abp基礎，請參考官方文檔

通用子產品：這個是使用abp子產品開發方式做的一些通用的，與具體業務無關的子產品，比如：資料字典子產品

業務子產品：工單管理、廣告管理、電商子產品等為了實作具體業務的子產品。

業務場景

客戶是做影印機出租的，它希望做一套系統管理整個業務，其中工單是一個比較重要的子產品，大緻流程如下：

  1. 客戶通過小程式上報工單，說明什麼裝置出了什麼問題
  2. 系統背景管理者檢視下大緻問題後稽核    
  3. 背景管理者将已稽核的工單配置設定給指定維修人員，或維修人員通過app自己領取已稽核的工單
  4. 當維修人員到達客戶處，通過app将工單設定為已執行狀态
  5. 當維修人員處理完任務後通過app将工單設定為已完成狀态，同時可能需要錄入完成情況說明

以上是主體流程，還有些邊角的以後文章會詳細說明，比如：從稽核狀态跳躍到已完成狀态；從已完成狀态回退到待稽核狀态；狀态變化時的事件等。

工單類型不同：有些工單可能并不是客戶送出的，比如當采購的二手裝置入庫時要做檢修，也會産生工單，這種情況工單不會與客戶關聯，而時與入庫單關聯；再比如讓某員工開車去托快遞回來這種情況工單會與物流資訊關聯

工單建立方式不同：客戶通過小程式送出、背景管理者手動建立、當發生某些事件時自動建立（比如采購入庫時自動建立）

其實工單管理子產品是個通用的業務，在很多系統可能都需要，是以考慮做成獨立的業務子產品，友善複用。

目标

可複用

工單子產品以nuget包釋出，你可以安裝後簡單配置後就可以使用。

易更新

上面說了，以nuget包形式釋出的，将來子產品更新後釋出新版本的nuget包，各系統更新下，引用新版本包就ok啦

獨立性

工單子產品隻依賴些通用的、非業務型的子產品。工單子產品需要用到“員工”概念，在系統中往往展現為一個使用者，工單子產品本身不提供“員工管理”的功能，因為你的系統可能有自己的“員工管理”功能；或你直接拿abp原始的 AbpUser作為員工也行。試想如果“工單子產品”本身提供了員工管理子產品，你引用過去，發現自己系統中已有實作了的員工管理，是不是很麻煩？

是以你的項目引用工單子產品時需要做個适配，為工單子產品提供需要用到的員工相關功能，主要是幾個查詢。

說明：

abp vNext使用契約層來實作子產品獨立化，個人認為不完整，比如你的項目中有個”員工管理“子產品，你在定義契約接口和DTO時隻能定義通用的，為了盡量通用，接口中的方法會盡量多，或分開多定義幾個接口，DTO中的屬性也會盡量多，因為你不知道将來哪各子產品引用你，是以你無法定義準确的、剛好夠用的接口和DTO。

現在有各”工資管理“子產品，引用你的”員工管理子產品“，它會拿到DTO中很多不必要的屬性，也會在引入接口時拿到很多不需要的方法。

再比如我的”工單子產品“如果直接引用你的契約，将來我釋出工單子產品，其它系統引用後，它必須去實作”員工契約“中的接口，它會很迷茫，我要實作這個契約中所有的接口嗎？DTO所有的屬性我都需要指派嗎？其實某些契約中的接口方法工單子產品可能根本不需要，同理契約中的DTO也不一定都需要指派。

還有更多問題，這些問題不影響使用，但挺别扭。出現這樣的原因，是獨立的業務子產品應該在契約中定義自己能向外提供什麼資料之外，還應該定義自己需要什麼，而不是讓别的子產品的契約來指定。

我們在開發工單子產品時，會從這兩個方向來定義契約，即：工單子產品需要什麼資料？工單子產品能向外提供什麼資料？

可擴充

abp本身提供了很強的擴充能力，你可以

  1. 通過“動态屬性系統”來擴充實體類
  2. 通過工單CRUD、工單狀态變化等事件來添加自己的業務邏輯
  3. 通過內建并替換工單子產品提供領域服務、應用服務來重寫現有業務邏輯
  4. 預設的UI隻是結合我自己的項目用easyui實作的，你可以實作自己的UI
  5. 通過內建抽象工單實體、抽象工單的領域服務、抽象的工單應用服務來實作更多的工單類型

使用DDD開發方式

實踐下DDD

核心業務邏輯在工單實體類中，它定義了相應的業務方法，内部會改變工單實體自身的一些狀态，必要時觸發相應事件，以此來確定工單始終能處于正确的狀态，比如：某個已完成的工單無關聯的員工或沒有開始和完成時間；再比如某個已拒絕的工單，沒有拒絕說明。如果實體的屬性都是public get; set; 很容易出現這種問題，因為協作開發時别人很可能胡亂調用你的實體，随意設定值。

領域服務有少量代碼，也觸發相應的領域事件。

應用服務來接收前端調用，協調領域實體和服務來實作業務邏輯。

關于DDD下篇詳細說明設計思路時再細說

內建

可擴充性中提到工單是抽象化的，但預設提供了一個”普通工單“的實作，是以安裝并配置子產品後此功能立即可用。另外也可用提供幾個子類實作一個自定義類型的工單。

線上demo：http://web1.cqyuzuji.com:9000/  賬号：admin 密碼：123qwe

先在abp官方下載下傳一個幹淨的abp項目，寫此文章時用的abp6.3 .net 5。或者你可用在你目前的項目引入并測試。按以下步驟進行配置。

安裝nuget包

相關nuget包都是以：BXJG.WorkOrder為字首的。

先確定：

在解決方案上右鍵 > 管了解決方案的包 > 更新 -> Castle.Windsor.MsDependencyInjection 更新到3.4.0

在解決方案上右鍵 > 管了解決方案的包 > 更新 -> Microsoft.EntityFrameworkCore 更新到5.0.4

XXX.Core層中 

Install-Package BXJG.WorkOrder.EFCore -Version 1.0.0-rc3

XXX.EntityFrameworkCore層中 

Install-Package BXJG.WorkOrder.EFCore -Version 1.0.0-rc3

XXX.Application層中 

Install-Package BXJG.WorkOrder.Application -Version 1.0.0-rc3      
Install-Package BXJG.WorkOrder.EmployeeApplication -Version 1.0.0-rc3

工單子產品中，背景管理工單和員工端對工單的操作是分開兩個應用層項目定義的，根據你的情況決定是否分開，若分開則上面的包需要分開安裝。

配置

在DbContext中注冊相關實體

由于工單子產品沒有使用獨立DbContext的方式，是以需要在你的主程式的DbContext中注冊并配置”普通工單“和“工單分類”的實體。在XXX.EntityFrameworkCore層中找到你的DbContext，做如下配置：

1         public virtual DbSet<BXJG.WorkOrder.WorkOrderCategory.CategoryEntity> BXJGWorkOrderCategory { get; set; }
2         public virtual DbSet<BXJG.WorkOrder.WorkOrder.OrderEntity> BXJGWorkOrder { get; set; }
3 
4         protected override void OnModelCreating(ModelBuilder modelBuilder)
5         {
6             base.OnModelCreating(modelBuilder);
7             modelBuilder.ApplyConfigurationBXJGWorkOrder();//别忘了這裡的映射配置
8         }

注冊權限和菜單

普通工單背景管理和員工端相關權限已定義為擴充方法，可以直接在主程式中調用，将其注冊到主程式的權限樹中。在XXX.Core/Authorization/XXXAuthorizationProvider中注冊【普通工單】和【工單分類】的權限，為了示範将權限注冊在了租戶權限下面。

admin.AddBXJGWorkOrderAllPermission();

同理在BXJG.Web.Mvc/Startup/XXXNavigationProvider中注冊【普通工單】和【工單分類】的菜單

context.Manager.MainMenu.AddBXJGWorkOrderAllNav();

預設情況會注冊 工單子產品的根、工單分類、預設工單的權限和菜單，可以調用另外幾個類似名稱的擴充方法來分别注冊需要的權限和菜單，你也完全可以按abp的方式完全自己定義權限和菜單的注冊，這種情況下，若你要使用預設工單的功能，權限的名稱必須對應，請參考預設工單權限常量名

注冊動态api

由于開發子產品時不确定你會如何使用工單子產品的應用層，是以預設并未自動注冊為動态web api，如果需要你可以自己配置，目前是手動，将來可能提供擴充方法一次性注冊。在XXX.Web.Core/XXXWebCoreModule的PreInitialize()中配置啟用工單子產品中普通工單和工單分類的相關動态web api

1 //注冊背景管理工單的動态api            
Configuration.Modules.AbpAspNetCore().CreateControllersForAppServices(typeof(BXJG.WorkOrder.ApplicationModule).Assembly,"bxjgworkorder");
2 //注冊背景和員工端管理工單的動态api               
Configuration.Modules.AbpAspNetCore().CreateControllersForAppServices(typeof(BXJG.WorkOrder.BXJGCommonApplicationModule).Assembly, "bxjgworkorder");
3 //注冊員工端管理工單的動态api                      
Configuration.Modules.AbpAspNetCore().CreateControllersForAppServices(typeof(BXJG.WorkOrder.BXJGWorkOrderEmployeeApplicationModule).Assembly, "bxjgworkorder");

添加子產品依賴

雖然已添加了子產品相關包引用，但此時這些包對于主程式來說僅僅是普通的dll，必須按abp的方式，讓主程式的子產品依賴工單子產品，這樣工單子產品中的dll才會以Abp子產品方式啟動。由于工單子產品隻提供到應用程式級别，是以在主程式的Application層中的Module類中添加依賴是最合适的。在XXX.Application/XXXApplicationModule中添加子產品依賴

[DependsOn(略...
               typeof(BXJG.WorkOrder.ApplicationModule),              
               typeof(BXJG.WorkOrder.BXJGWorkOrderEmployeeApplicationModule))]
    public class XXXApplicationModule : AbpModule
    {

添加子產品适配代碼

如前所述，工單子產品對員工的依賴是通過IEmployeeAppService接口隔離的，預設将AbpUser作為員工，但設計子產品時無法确定你的使用者類型，是以需要在你的主程式XXXApplicationModule.Initialize()按如下方式注冊服務

IocManager.RegisterBXJGWorkOrderDefaultAdapter<User>();//User為你項目的使用者類型

當然這個服務是可以替換的。

另外員工端對工單的管理服務中需要擷取目前登陸的員工，是以規定了IEmployeeSession接口，預設使用abp提供的IAbpSession，這個不需要做任何配置，當然你也可以替換這個服務

資料庫遷移

這個是按abp的套路，這不再詳述。注意abp預設下載下傳來的項目連接配接字元串是連接配接到localhost的，而vs2019的localdb稍有不同，我是改成如下形式的，你看着辦

"Default": "Server=(localDB)\\mssqllocaldb; Database=BXJGDB; Trusted_Connection=True;"

運作

不出意外的話接口就可以通路了

abp加DDD開發：低耦合、可複用、可擴充的【工單】業務子產品-簡介和內建
abp加DDD開發：低耦合、可複用、可擴充的【工單】業務子產品-簡介和內建
  • WorkOrder：背景管理者對工單進行管理的接口，其中ChangeStatus是将工單跳躍或回退到指定狀态，這個操作不是一步到位的，比如從”待稽核“狀态 跳躍到 ”已完成“中間會經曆：确認、配置設定、執行、完成等步驟，操作員必須有這些步驟的權限，切工單狀态必須正确（打個比方，配置設定時會判斷工單是否已關聯的處理人，隻是假設，目前沒做這個限制），這部分邏輯大多在工單實體中。
  • WorkOrderCategory：背景管理者對工單分類進行維護的接口
  • WorkOrderCommon：員工端或背景管理端都可以調用的接口，用來擷取工單狀态清單、緊急程度清單等
  • WorkOrderEmployee：員工端對工單進行操作的接口，擷取待配置設定的工單、執行、完成工單等。 

後續

  • 目前已實作真正的獨立的業務子產品
  • 配置還需要進一步簡化
  • 目前隻是基本能跑通工單流程，未作詳細測試。
  • 上面說明了子產品的基本內建，以及子產品内預設實作的“普通工單”的功能，如何擴充後續會說明，比如：實作自定義類型的工單、如何通過繼承、事件等方式來擴充工單子產品等。
  • 目前子產品隻提供到應用層級别，也就是隻提供後端接口，前端我使用的easyui，雖然可以使用abp的虛拟檔案系統來實作UI子產品化，但目前沒有這樣做，你可以使用自己喜歡的架構來完成UI

用支付寶掃一掃，咱倆都可以獲得一個小紅包

關注我的今日頭條，有不錯的c#.net經驗分享

本文來自部落格園，作者：變形精怪，轉載請注明原文連結：https://www.cnblogs.com/jionsoft/p/14609531.html

abp子產品
上一篇: 用領域驅動DDD的方式實作購物車-基于abp一代6.2
下一篇: 密碼套件：密碼，算法和協商安全設定（一）