生成脚手架 随着新框架的不断稳定(同时也带来了不错的收益),新的项目以及重构项目不断的往新框架上切,基于这个原因,要把新框架整一个脚手架。 脚手架中包含了demo(为了学习而框架,实际开发中会有一些便利性的调整) 注意事项 依赖maven环境,必须配置MVAVA_HOME 依赖jdk环境(一定要jdk,不要jre) maven-archetype 的模板使用velocity 引入插件以及自定义配置文件 先找一个可以跑起来的demo,在pom文件中引入脚手架的maven plugin 我的工程结构如下: 项目地址:h…

2021/11/29 0条评论 2021点热度 0人点赞 阅读全文

没错,又来了,一个项目的结束,就会复盘并完善下。 传统开发的弊病: 通过事务脚本模式来开发需求; 开发人员热衷于技术并通过技术手段解决问题,而不是深入思考和设计业务的走向; 过于重视数据库,围绕数据库和数据模型进行建模,按数据流程进行建模; 按技术视角进行业务命名,导致后续迭代以及人员更替时,产品和技术无法对齐; 随着业务的发展,到后续业务、技术无法沟通,各种不理解; 业务希望技术出排期,技术得撸代码,耗费精力; 代码开发的过程中技术和业务耦合,一个场景一个服务,代码流水线; 因为技术的问题会导致业务流程的中断,导…

2021/09/20 0条评论 1219点热度 0人点赞 阅读全文

上周分享了一篇文章(DDD的应用框架实践分享) 周五又在内部将给大家分享了下。现将分享内容与大家分享。 传统开发的弊病: 通过事务脚本模式来开发需求; 开发人员热衷于技术并通过技术手段解决问题,而不是深入思考和设计业务的走向; 过于重视数据库,围绕数据库和数据模型进行建模,按数据流程进行建模; 按技术视角进行业务命名,导致后续迭代以及人员更替时,产品和技术无法对齐; 随着业务的发展,到后续业务、技术无法沟通,各种不理解; 业务希望技术出排期,技术得撸代码,耗费精力; 代码开发的过程中技术和业务耦合,一个场景一个服务…

2021/07/19 0条评论 1348点热度 0人点赞 阅读全文

分享一个DDD的应用框架,写了一个简单的demo。 已经在在生产实践。 git地址:https://github.com/yxkong/ddd-framework 框架结构如下: 项目结构如下: 示例流程图: 简单说明: 只启动一个应用在adapter层启动; 接口请求到adapter层,调用DistributeController; controller层做上下文转化以及调用application层; application层进行模型依赖构建,以及领域执行前后的特殊处理; domain层进行了业务逻辑实现(和技术…

2021/07/14 0条评论 1468点热度 0人点赞 阅读全文

5ycode 被管理耽误的架构师。工作、学习过程中的知识总结与分享,jvm,多线程,架构设计,经验分享等。 28篇原创内容 公众号 痛点 如何分层 无领域专家 底层数据固定,不想做大的改动 值对象、实体、聚合根拆分困难 先说如何分层 先看下六边形架构  如图我将项目分为四层 领域层 也是最底层,整个核心的业务逻辑在此封装 封装了业务逻辑、定义了领域模型和实体(不对聚合根、值对象、实体做太多的划分) 如果业务逻辑设计领域较多,可以封装领域服务 此层是面向接口编程,不关注实现 数据从哪来,我不管,我就要这样的…

2021/06/03 0条评论 1741点热度 0人点赞 阅读全文

第一章DDD对我而言 还可以指引构建正确软件模型的方向。 领域驱动对团队人的要求较高: 具备深厚的业务能力(领域专家) 具备业务抽象能力; 具备技术抽象能力 DDD 领域驱动设计 可以实现目标 如果你希望打磨软件匠艺并提高项目的成功率; 如果你迫切期望创造软件来帮助企业把业务竞争力提升到新高度; 如果你期望实现出来的软件既能正确地对业务需求建模又可以采用最新建的软件架构进行扩张; 设计 设计是不可或缺的,除了优秀设计就是糟糕设计,根本不存在不做设计. 有效设计(Effective Design) 可以满足商业组织希…

2021/04/06 0条评论 1258点热度 0人点赞 阅读全文