项目名称:KeepGoing(继续前进)

工作后，学习的脚步一直停停走走，希望可以以此项目为基础，可以不断的迫使自己不断的学习以及成长

将以Girvs框架为基础，从壹开始二次开发一个前后端管理框架

在这过程中一步步去学习使用到的技术点，也同时会将在此过程中遇到的问题进行分享

后端开发语言：C#

后端开发平台：.Net6

前端开发框架：Vue3

方案整体结构如下

**KeepGoing.WebApi Api接口层

KeepGoing.Application 应用层

KeepGoing.Domain 领域层

KeepGoing.Infrastructure 基础数据层**

KeepGoing.WebApi

• Girvs.Swagger 主要引用Swagger包,以及Girvs主框架包
• Microsoft.EntityFrameworkCore.Tools包 数据库迁移文件命令

KeepGoing.Application

• Girvs.DynamicWebApi 生成动态API
• Girvs.AuthorizePermission 用户用户授权

KeepGoing.Domain

• Girvs.AuthorizePermission 用户用户授权

KeepGoing.Infrastructure

• Girvs.EntityFrameworkCore 数据库持久化

ConfigureApplicationServices代码如下

个人对其中一些代码的理解

services.AddBindAppModelConfiguation(configuration, appSettings);

初始化appsettings.json配置文件，并绑定到Configuration

services.AddBindSerilogConfiguation(configuration);

初始化Serilog.json配置文件

IEngine engine = EngineContext.Create();
engine.ConfigureServices(services, configuration);

创建引擎,配置服务

1.6.1 创建用户实体

在KeepGoing.Domain添加Models文件夹，文件夹下添加User.cs 类文件

public class User : AggregateRoot<Guid>, IIncludeInitField, IIncludeMultiTenant<Guid>, IIncludeCreateTime, IIncludeCreatorId<Guid>
    {

        /// <summary>
        /// 登陆名称
        /// </summary>
        public string UserAccount { get; set; }

        /// <summary>
        /// 用户密码
        /// </summary>
        public string UserPassword { get; set; }

        /// <summary>
        /// 用户名称
        /// </summary>
        public string UserName { get; set; }

        /// <summary>
        /// 用户联系方式
        /// </summary>
        public string? ContactNumber { get; set; }

        /// <summary>
        /// 用户类型
        /// </summary>
        public UserType UserType { get; set; }

        /// <summary>
        /// 是否初始化数据
        /// </summary>
        public bool IsInitData { get; set; }

        /// <summary>
        /// 租户ID
        /// </summary>
        public Guid TenantId { get; set; }

        public DateTime CreateTime { get; set; }

        public Guid CreatorId { get; set; }
    }

主要包含用户基础信息

1.6.2 添加 EntityTypeConfiguration

在KeepGoing.Infrastructure下创建EntityConfigurations文件夹，在文件夹下面建立UserEntityTypeConfiguration

主要作用是进行数据库映射，并添加种子数据,以及建议一些索引

1.6.3 添加DbContext

在KeepGoing.Infrastructure创建KeepGoingDbContext.cs类文件

[Girvs.EntityFrameworkCore.DbContextExtensions.GirvsDbConfig("KeepGoing")]

主要用户绑定到指定的数据库配置文件,如果有多个数据库,可以创建多个DbContext类文件,并添加以上特性

启动程序是会在appsettings.json中生成对应的配置节点

启动后的appsettings.json文件大致如下

可以在这里进行数据库配置，下面简单介绍一些参数

UseDataType 连接数据库类型 0 sqlServer 1 mysql

VersionNumber 数据库版本

SQLCommandTimeout 默认执行超时时间

MasterDataConnectionString 主数据库连接字符串

1.6.4添加IUserRepository

在KeepGoing.Domain下创建IRepositories文件夹，文件夹下创建IUserRepository.cs文件

定义一个获取用户接口

1.6.5添加UserRepository

在KeepGoing.Infrastructure下创建Repositories文件夹，文件夹下创建UserRepository.cs文件

实现获取用户接口

1.6.6添加IUserService、UserService

在KeepGoing.Application项目下创建AppService\User文件夹，文件夹下创建IUserService.cs、UserService.cs类文件

定义用户登录获取token接口并进行实现,这里已经封装了Jwt生成Token方法,直接调用

此时,获取用户接口全流程全部完成了

1.6.7 生成迁移文件，并生成数据库

打开程序包管理控制台,设置默认项目为：KeepGoing.WebApi

运行

add-migration init

update-database

这时将会生成对应的数据库

1.6.8 运行项目

这里看到，默认启用了swagger,并增加了Authorize授权,以及获取token接口

闲谈下对DDD的理解

DDD介绍(来源GPT)

DDD（Domain-Driven Design，领域驱动设计）是一种软件开发方法论，主要关注解决复杂业务领域的问题。DDD的核心思想是将软件系统按照真实世界的业务领域模型进行划分和设计，让领域专家和开发团队共同参与设计过程，以实现高内聚、低耦合的架构。

DDD强调将领域模型和业务逻辑置于核心位置，通过分层和模块化的方式构建可复用和可维护的软件系统。它提倡使用统一的语言和概念来描述领域模型，以便于沟通和理解。另外，DDD还推崇使用领域事件、聚合根、实体、值对象等概念来描述和组织领域模型的结构。

除了领域模型的设计，DDD还关注业务模型的边界划分和限界上下文的定义。限界上下文是指业务领域中的一个隔离环境，将特定的业务概念和规则进行封装。这有助于避免不同领域之间的混淆和冲突，同时在大型项目中也可以实现团队的自治和解耦。

DDD还提供了一系列的设计模式和战术技巧，例如聚合根、领域服务、领域事件等，以帮助开发人员更好地实现领域模型和业务逻辑。最终，DDD的目标是提供一种更加灵活、可扩展和可维护的软件设计方法，以适应复杂业务领域的需求。

个人对DDD的理解：

DDD不同于传统三层架构的地方在于它更关注业务,将重点从数据库设计倾向于业务设计，其中的领域事件、聚合根、实体、值对象都是服务于业务。也就是这样它能够应对更为复杂、变化更频繁的业务场景。业务独立且不受干扰，方便扩展以及拆分成各个子系统。

结合自己以及身边的同事，对于DDD、传统框架开发中感受到的不同点进行一个汇总：

1.DDD开发对比传统框架变得更'麻烦',如果能够理解其中各个层级意义，个人觉得是变得更简单

• 传统架构写增删改查,定义Api接口->业务逻辑处理(BLL)->调用数据访问层(DAL)
• DDD中写增删改查,查询用到Query查询处理(读请求),增删改用到Command(命令),其中查询输入输出模型又会用到AutoMap转换成领域中使用到的对象

2.DDD层级对比传统框架层级更多，但代码架构更清晰一些

3.DDD整体系统各部分松耦合，可扩展性好

4.CQ两端架构分离、相互不受束缚，各自独立设计、扩展

5.DDD 系统复杂层度更高，一般小型快速开发项目采用传统三层开发效率会高很多

todo…

这上面只是个人的一些理解，如果其中有些错误的地方，还希望大家帮忙指出