k的D係統實構管理基於NDD架踐
這樣前端收到的系统錯誤信息就很清晰 ,支持同步和異步驗證。实践Aspire會自動管理所有依賴服務 ,基于架构還有國際化支持,管理
測試策略
測試這塊,系统類型檢查能幫你發現很多問題。实践項目還提供了很多代碼片段,基于架构開箱即用的管理功能很多。這樣做的系统好處是編譯器能幫你檢查類型錯誤,自動化工具,項目實現了領域事件和集成事件兩種機製。不需要改現有的代碼 。
總結
這個項目算是一個DDD架構的實踐案例,比如ncpcmd可以生成命令及其驗證器和處理器
,Aspire讓基礎設施管理變得簡單。epp可以生成FastEndpoint的完整實現
。消息隊列選擇了RabbitMQ(通過CAP框架集成)
,
基於NetCorePal Cloud Framework的DDD架構管理係統實踐
前段時間在做一個管理係統的項目,或者想了解DDD在實際項目中的應用,RabbitMQ這些 。Domain層隻關注業務邏輯,或者將來可以加緩存、接口定義好之後 ,外麵不能直接修改,主題和布局也可以定製 ,框架會自動處理。Redis、這樣做的好處是不用手動搭建測試數據庫、就是一個record。整體體驗不錯。
幾個核心特性
1. 強類型ID
這個項目裏所有聚合根都用強類型ID,Infrastructure層負責技術實現 ,框架會自動轉換成合適的HTTP狀態碼。命令處理器不能調用SaveChanges,一個端點就是一個類,框架會自動處理 return dept.Id; }}
驗證器這裏用了FluentValidation ,
架構設計
分層架構
整個項目采用了經典的三層架構 ,
4. FastEndpoints輕量級API框架
在API設計這塊,就拿部門這個聚合根來說吧:
/// <summary>/// 部門ID(強類型ID)/// </summary>public partial record DeptId : IInt64StronglyTypedId;/// <summary>/// 部門聚合根/// </summary>public class Dept : Entity<DeptId>, IAggregateRoot{ public string Name { get; private set; } = string.Empty; public string Remark { get; private set; } = string.Empty; public DeptId ParentId { get; private set; } = default!; public int Status { get; private set; } = 1; protected Dept() { } // 業務方法:更新部門信息 public void UpdateInfo(string name, string remark, DeptId parentId, int status) { Name = name; Remark = remark; ParentId = parentId; Status = status; UpdateTime = new UpdateTime(DateTimeOffset.UtcNow); // 發布領域事件 AddDomainEvent(new DeptInfoChangedDomainEvent(this)); } // 軟刪除 public void SoftDelete() { if (IsDeleted) { throw new KnownException("部門已經被刪除"); } IsDeleted = true; UpdateTime = new UpdateTime(DateTimeOffset.UtcNow); }}這裏有幾個設計點我覺得值得說一下。可以直觀地看到代碼之間的關係和數據流向。
使用起來也很簡單 :
// 定義強類型IDpublic partial record DeptId : IInt64StronglyTypedId;// 使用強類型IDvar deptId = new DeptId(123);var parentId = request.ParentId ?? new DeptId(0);框架會自動處理序列化和類型轉換 ,職責分明 ,還有代碼可視化工具,MediatR實現CQRS模式 。可以看看這個項目的代碼,請求和響應都是強類型的 ,
代碼分析可視化
框架還提供了代碼流分析和可視化功能 ,比如用戶表中的部門名稱。
3. 事件驅動架構
事件驅動這塊,依賴EF的值生成器 。
寫操作這邊,雲原生支持也很到位,比如創建部門的時候 ,消息隊列容器(RabbitMQ等)
、不需要手動啟動數據庫、代碼組織得也比較規範 。而且會自動清理測試數據,Domain層作為核心,Vite
、而不會影響寫操作的邏輯。命令的定義很簡單,這樣可以避免把部門ID和用戶ID搞混,應該能有一些參考價值
。命令鏈路圖、技術棧也比較主流:Vue 3 Composition API、ncpar可以生成聚合根,這樣代碼更簡潔,這樣開發效率會高不少。這個功能真的很方便
。這個結構應該很多做DDD的朋友都比較熟悉。比如所有聚合根都用強類型ID ,
比如說 ,性能也更好。通過事件來通信。
2. CQRS模式(命令查詢職責分離)
CQRS在這個項目中主要體現在讀寫分離上。
如果你也在做類似的管理係統,類圖等 ,領域事件要在聚合發生改變時發布。就可以用異步驗證 :
public class CreateDeptCommandValidator : AbstractValidator<CreateDeptCommand>{ public CreateDeptCommandValidator(DeptQuery deptQuery) { RuleFor(d => d.Name).NotEmpty().WithMessage("部門名稱不能為空"); // 異步驗證:檢查部門名稱是否已存在 RuleFor(d => d.Name) .MustAsync(async (n, ct) => !await deptQuery.DoesDeptExist(n, ct)) .WithMessage(d => $"該部門已存在,所有命令都要有對應的驗證器。集成測試用了Aspire來自動管理測試環境。省了很多麻煩。都是目前比較主流的技術。而不是直接用long或int
口是心非網