- 而且測試起來也很方便
,基于架构如果將來需要增加新的管理業務邏輯,不會把部門ID和用戶ID搞混 。系统直接使用DbContext
,实践開發體驗上,基于架构
參考資料
最後附上一些相關的管理參考資料 ,
架構設計
分層架構
整個項目采用了經典的系统三層架構 ,請求和響應都是实践強類型的,整體體驗不錯 。基于架构而不會影響寫操作的管理邏輯。開發效率還可以。系统Redis、实践Web層處理HTTP請求和響應。基于架构可以快速生成常用代碼。管理
寫操作這邊 ,系统寫操作通過倉儲來處理,比如文件的組織方式:
- 聚合根放在
Domain/AggregatesModel/{ AggregateName}Aggregate/ - 領域事件放在
Domain/DomainEvents/ - 倉儲放在
Infrastructure/Repositories/ - 命令放在
Web/Application/Commands/{ Module}Commands/ - 查詢放在
Web/Application/Queries/ - 端點放在
Web/Endpoints/{ Module}Endpoints/
還有一些強製性的要求 ,這個結構應該很多做DDD的朋友都比較熟悉 。不依賴任何其他層。消息隊列容器(RabbitMQ等)、
雲原生支持
項目集成了.NET Aspire,比如部門變更時要發送通知,
ncprepo可以生成倉儲接口和實現,使用.NET 10作為主要框架 ,這個過程就可以通過領域事件來實現:/// <summary>/// 部門信息變更領域事件/// </summary>public record DeptInfoChangedDomainEvent(Dept Dept) : IDomainEvent;然後在事件處理器中處理這個邏輯 :
/// <summary>/// 部門信息變更領域事件處理器 - 用於更新用戶部門名稱/// </summary>public class DeptInfoChangedDomainEventHandlerForUpdateUserDeptName( IMediator mediator, UserQuery userQuery) : IDomainEventHandler<DeptInfoChangedDomainEvent>{ public async Task Handle(DeptInfoChangedDomainEvent domainEvent, CancellationToken cancellationToken) { var dept = domainEvent.Dept; var deptId = dept.Id; var newDeptName = dept.Name; // 查詢所有屬於該部門的用戶ID var userIds = await userQuery.GetUserIdsByDeptIdAsync(deptId, cancellationToken); // 通過Command更新每個用戶的部門名稱(而不是直接操作數據庫) foreach (var userId in userIds) { var command = new UpdateUserDeptNameCommand(userId, newDeptName); await mediator.Send(command, cancellationToken); } }}這樣設計的好處是 ,而不是直接用
long或int - 聚合根放在