# xby_golang **Repository Path**: pretty_tech/xby_golang ## Basic Information - **Project Name**: xby_golang - **Description**: 我的golang工具集合 - **Primary Language**: Go - **License**: MIT - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2020-08-28 - **Last Updated**: 2021-03-28 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README #说明 ## 命名规则 - 名称处理 文件夹 - 逻辑名 如 api interface config （小写）这样的 这个一般放最前面 - 包名保证全称即可，不然命名很麻烦 - 功能名(意义名) 如 login Token Sms 这样的 （首字母要大写） - 连接词 ， - By 用在动词当中 - 重点在前面的动词 最后要用By 连接 这个用在执行意义的名称中 - 方法名 - 前缀 + 功能名放后面即可 - 原则是动词放前面能达到 可理解效果 - 方法 Get 是得到值 - Act 表示直接执行的方法 区别于名词系 - Load 是 赋值给本结构的属性 - New 创建本结构体 - Create 非本结构体里内容 创建外部 - Update -Loc 本地 -Rem 远程 - 特例 api 控制器文件夹 - 1. 底下文件夹是否加前缀 ? 初步 定为 逻辑分类 文件夹不用加 ###但是具有引用行为的包名行为必须加 ####但是文件必须加 - js 方法名 - 和 golang 一样吧 ，被外部引用 大写 内部小写 - 具有更广泛意义的词 放在前面 区别放后面 - 逻辑文件夹，子文件夹将始终包含此逻辑，用逻辑名做文件夹 - 但是只要有广泛逻辑意义的词 就放前面 逻辑包名 如 login sms ## 文档 - https://65480539.gitbook.io/ - 获取机器mac地址: - https://blog.csdn.net/qq_37974048/article/details/107966346 - 生成唯一 ID - https://github.com/sony/sonyflakz ## 参考项目 - gin-vue-admin - https://github.com/flipped-aurora/gin-vue-admin ##想法 - 商品 库存 - 订单在导出的时候 设置一个状态 ， 不能修改 了 - 关于用户Id 是否传的问题 - 其实给的是Token ID 是不用给的 ##规范 - 不具备实用意义 仅仅是分层架构的 文件夹 使用 小写 否则大写 - 然后以 大写开头 后面意义名 作为 分包 ##Mysql - COALESCE 函数 取非空的 ## 技巧 - 如不需json 解析必须 用json:"-" - ###判断linux 文件是否存在 - ```[ -f hello.txt ] && echo yes || echo no``` - 应该是操作不了 远程的git - 使用sftp包上传 文件夹及文件 - [出处](https://blog.csdn.net/fu_qin/article/details/78741854) - 调试技巧 - F12 step over - ctrl + F12 clear file breakpoints - command + F12 clear all breakpoints - F10 调试运行 - F9 打开debug 窗口 - F8 恢复运行 - test文件夹里用internal 文件夹 ，目的是为了防止 外部调用 - 别忘了goft.Error 用panic 处理 错误 - 项目设计技巧 - 价格表单独列出 ，区别 双 11 价格 普通价格 之类的分别 - 用 is_current 来区别 是否是当前的 ### jwt 名词解释 - https://www.jianshu.com/p/fcc1a6482143?from=timeline - NotBefore iss(Issuser)：代表这个JWT的签发主体； sub(Subject)：代表这个JWT的主体，即它的所有人； aud(Audience)：代表这个JWT的接收对象； exp(Expiration time)：是一个时间戳，代表这个JWT的过期时间； nbf(Not Before)：是一个时间戳，代表这个JWT生效的开始时间，意味着在这个时间之前验证JWT是会失败的； iat(Issued at)：是一个时间戳，代表这个JWT的签发时间； jti(JWT ID)：是JWT的唯一标识。 b. Public claims，略（不重要） c. Private claims， ### 类型转换 - 结尾如果是 interface的别名 ,应该可以用其他名称转换 ### DDD领域模型 - [DDD文档出处](https://www.jianshu.com/p/6e2917551e63) - 领域 - 服务 - 领域服务还是应用服务 - 我们可以理解为服务是行为的抽象。从前缀来看，根据DDD的经典分层架构，它们又隶属于不同的层，应用服务属于应用层，领域服务属于领域层。 - user Interface | Application | Domain | Infrastructure - 应用层（Application）：负责展现层与领域层之间的协调，协调业务对象来执行特定的应用程序任务。它不包含业务逻辑。 - 领域层（Domain）：负责表达业务概念，业务状态信息以及业务规则，是业务软件的核心 - 所以综合来看应用服务是用来表述应用行为，而领域服务用来表述领域行为。 - 什么叫 应用行为？领域行为? - 应用行为 shenyi 用作 响应请求的直接处理 - 应用服务是用来表达用例和用户故事（User Story)的主要手段。 应用层通过应用服务接口来暴露系统的全部功能。在应用服务的实现中，它负责编排和转发，它将要实现的功能委托给一个或多个领域对象来实现，它本身只负责处理业务用例的执行顺序以及结果的拼装。通过这样一种方式，它隐藏了领域层的复杂性及其内部实现机制。 应用层相对来说是较“薄”的一层，除了定义应用服务之外，在该层我们可以进行安全认证，权限校验，持久化事务控制，或者向其他系统发生基于事件的消息通知，另外还可以用于创建邮件以发送给客户等。 应用层作为展现层与领域层的桥梁。展现层使用VO（视图模型）进行界面展示，与应用层通过DTO（数据传输对象）进行数据交互，从而达到展现层与DO（领域对象）解耦的目的。 - 那么领域行为 就是 进行 领域上下文的运算 应该是被调用的关系 由仓储定义 - 领域层就是较“胖”的一层，因为它实现了全部业务逻辑并且通过各种校验手段保证业务正确性。而什么是业务逻辑呢？业务流程、业务策略、业务规则、完整性约束等。 当领域中的某个操作过程或转换过程不是实体或值对象的职责时，我们便应该将该操作放在一个单独的接口中，即领域服务。请确保该服务和通用语言时一致的；并且保证它是无状态的。 - 根据这句话我们有几个问题需要理清： 什么时候使用领域服务？ 领域服务无状态怎么理解？ 领域服务是用来协调领域对象完成某个操作，用来处理业务逻辑的，它本身是一个行为，所以是无状态的。状态由领域对象（具有状态和行为）保存。 上面也说了，领域对象是具有状态和行为的。那就是说我们也可以在实体或值对象来处理业务逻辑。那我们该如何取舍呢？ 一般来说，在下面的几种情况下，我们可以使用领域服务： 执行一个显著的业务操作过程 对领域对象进行转换 以多个领域对象为输入，返回一个值对象。 - 服务是行为的抽象。 应用服务通过委托领域对象和领域服务来表达用例和用户故事。 领域对象（实体和值对象）负责单一操作。 领域服务用于协调多个领域对象共同完成某个业务操作。 应用服务不处理业务逻辑，领域服务处理业务逻辑。 - 领域事件 - 违反了聚合的一大原则：在一个事务中，只对一个聚合进行修改。在这个用例中，很明显我们在一个事务中对订单聚合和库存聚合进行了修改。 - 解决 解耦，可以通过发布订阅模式，发布领域事件，让订阅者自行订阅； 通过领域事件来达到最终一致性，提高系统的稳定性和性能； 事件溯源； 等等。 也可以简要理解为：领域事件 = 事件发布 + 事件存储 + 事件分发 + 事件处理。 - 时间万物 重点在于划分 领域可认为是一个问题的边界 - 实体、值对象、聚合，也会逐渐地形成一个复杂领域模型 - 基于上下文图的策略性领域驱动开发 - 文档 https://www.infoq.cn/article/ddd-contextmapping/ - 用户层面 - PFM 这个缩写可代表用户层 - 仓储层（聚合的管理） - 而我们要讲的仓储就类似于仓库管理员，只不过它负责的不再是货物的管理，而是聚合的管理，仓储介于领域模型和数据模型之间，主要用于聚合的持久化和检索。它隔离了领域模型和数据模型，以便我们关注于领域模型而不需要考虑如何进行持久化。 - 着重看一下 4.1. 仓储方法需明确 接口方法必须要有意义 否则无需定义 仓储作为领域模型和数据模型的中介，它负责映射领域模型到持久化存储。 仓储实现了透明持久化，即领域层不需要关注领域对象如何持久化。 仓储是一个契约，而不是数据访问层。它明确表明聚合所必需的数据操作。 ORM框架不是仓储。仓储是一种架构模式。ORM用来以面向对象的方式来表示数据模型。仓储使用ORM来协调领域模型和数据模型。 仓储适用于具有丰富领域模型的限界上下文。对于没有复杂业务逻辑的简单限界上下文，直接使用持久化框架即可。 使用UOW进行事务管理。UOW负责跟踪对象的状态，仓储在UOW协调的事务中进行实际的持久化工作。 仓储用于管理单个聚合，它不应该控制事务。 ### 建立索引原则 -[mysql索引文档](https://blog.csdn.net/ztx114/article/details/100033662) ### 学会一门语言需要 什么 0. 掌握基本语法 1. 学会使用 循环 注入模式套路 2. 生成唯一 id 3. 读取配置文件 4. 连接数据库 5. 时间戳与日期格式的转换