程序男的专栏

cpu问题排查过程

cd 到src/java目录，打zip包。打纯源码包给第三方进行安全漏洞扫描。项目中加入下面的maven 插件。

通过上面的方案探讨和优缺点分析发现，想做好分布式本地缓存刷新功能借助不同的中间件实现是没有太多难度的，重点是上量之后出现的性能问题和可用性问题(实时性)。节点数量一定时间内的刷新量面对大规模的服务集群如果需要高可用性可能需要上面的多种方案结合才行。比如选消息中间件作为主方案，使用轮询的方式作为兜底方案等。

最近公司准备进行业务组件的开发，正好我也准备讲一下《DDD理论与实践》的技术分享，在进行通用业务组件设计方案的时候发现了一个特别容易理解也很容易讲明白的案例，这里专门记录一下，分享给大家。...

今年在DDDChina上认识了很多行业大佬，也跟着学习了一波，在领域建模的过程中关于实体，值对象和聚合的讨论比较多，也看了一些大佬的书。在大佬眼力进行领域模型设计的时候把聚合当作基本单元看着是比较随意的事情，但是对于初学者来说可能还需要一些时间消化。这里来简单探讨下整个问题。......

上一篇重点讲述了软件复杂度的由来和现象，以及不同视角下的复杂度是怎么呈现的，本篇文章将从更细致的方面来阐述形成复杂度的一些指标数据，并按不同维度进行区分。这么做的一个原因就是希望通过本篇文章让软件复杂度更具象，让软件开发者更直白全面的感受复杂度。...

自从Eric的书名中提到如何应对软件复杂度的问题，后面的很多其他大佬都在尝试用自己的方式来阐述软件复杂度和如何应对软件复杂度。但是我们可能忽略了一个基本的问题就是我们如何衡量它。在软件架构工程中有一些复杂度函数，比如neal的适应度函数等。比如一些衡量耦合相关的指标和数学函数信息，但是这只是整个软件工程中的某个方面的复杂度的信息，对大多数软件从业者来说，这显得有点专业了。...

基于上下文的业务流建模法的文章系列已经到了第四篇了，本篇也是最后一篇，来讲一下关于这个建模方法的一些缺点以及如何优化它，基于这个建模方法我们如何更好更快的构建业务模型。

前面两篇文章已经给大家展示了一个相对新颖的建模方法，也简单实战了下，这里我通过一个生活中的例子来模拟快递业务中的模型构建过程，本篇将完整的展示一下基于上下文的业务流建模法的操作过程。...

上一篇文章说到了我提出了一种新的建模方法，并对建模方法的大概内容做了阐述，本次我将继续对这个建模方法做进一步的说明,并提供一个小小的案例来熟悉一下建模套路。下一篇文章将通过其他案例来展示这种建模方法的优势。...

上一篇我们讲到了统一语言与各个方面因素的关系，从这些关系中可以看出如果要让统一语言统一，同时带来一定的收益，我们就要深入去了解统一语言可管理可控制的一些方法或者工具，本篇将从工具的角度来阐述一下统一语言在用工具管理过程中出现的一些问题，以及为什么这些工具没有发挥最好的效果。

在上一篇文章中，重点讲述了统一语言在文化等方面存在的一些差异，这些差异本身也体现了世界的差异，包括国与国之间,人与人之间等的互动是客观存在不一致的，那么统一语言本身而言就无法达到高度统一，但是有可能是可以达到共识的，本篇将从统一语言与其他方面的关系来简单阐述一下统一语言为什么不能统一的问题。

学了DDD也大半年了，看事物也总喜欢从更多的维度去看，因此对于需求而言，总可以归为从问题空间到解空间的映射。不过有时候这种从领域的角度或者领域驱动设计的方式去跟人沟通的时候发现是挺痛苦的，毕竟需要去理解不同的人在不同的上下游说的不同的词是什么意思，是不是指的同一个事物，同一个系统，同一个场景。所以，当从领域驱动设计的统一语言模式去应用的时候，其实还是非常难的。因此，本系列将探究一个关于DDD统一语言模式的问题，以及可能的解决方法。

最近通过COLA构建篮球运营管理平台演示源码的时候对跨层调用做了一些深度思考，在跨层调用中有些调用并不是严格按规范或者相对固定的分层模式去走的，这就出现了一些疑问，比如不按规范来我怎么控制代码质量，我怎么知道最佳实践是什么？

在DDD讨论群中与一位群友讨论了一个关于领域服务拆分的问题，这个也涉及到了代码层面的操作和设计，比如一个领域服务中包含多个子领域，随着业务的发展或者迭代，某个子领域需要拆出来独立迭代。很多程序员多少都会遇到这种情况，尤其是分布式微服务下的架构模式，因此本文就这个话题着重讨论一下DDD中的领域上下文的拆分和合并。

这个话题是突然间从脑海中闪过的，感觉有点意思，可以聊一下，类似于学习的三种境界。很多技术文章或者技术人都会有这三种境界，现在带大家感受一下。

最近看了一些大佬的公众号以及一些培训DDD的宣传课程，发现有很多都在宣传基于事件驱动的领域建模方法，这里就简单分析一下为什么大佬们都喜欢用这个方法来构建领域模型。

一、背景在前一段时间里有一篇文章比较火，说service必须要有个实现接口吗？这个在各大公众号上进行转载，引起Java技术网友的广泛评论，我也简单说了下个人的观点。最近正好也在不同的场景用到了独立类，没有实现接口。本文将结合DDD的独立类模式来重点探讨如何用好独立类，如果才不一刀切的看待独立类的使用。二、独立类简述2.1 独立类的简单概括简单来说就是没有实现接口，没有实现抽象类的Java类，当然枚举和注解这里不是我们讨论的话题。2.2 哪些算是独立类通常来说很少有机会对模型进行实现接口比如DTO

之前群里有人分享基于贫血模型和充血模型相关的一些代码实战，同时也有一些小伙伴不太理解这些模型之间的真正内容，本文将通过一个扣库存的代码工程实践来阐述不同视角下的扣库存逻辑的实现。

最近有微信朋友在公司内部分享的时候有人问领域划分的规则是什么？意思就是你怎么知道一个领域需要划分哪些子领域？有没有依据，是凭直觉吗？本文将重点讨论下这个比较现实的问题。同时根据网友的试读建议本文进行了思维导图的总结，可以保存收藏。

在两个月前我扩展了基于调用时序的代码生成，将代码生成的粒度从代码方法级别提升到了代码行级别，从整个迭代过程来看也逐步积累了一些问题，在一些模块设计上实现的不够好，同时没有扩展到springcloud体系，另外也在这一段时间重点看了很多低代码的实现，比如易鲸云，简道云，金蝶云等等，我发现如果需要把codeMaker提升到企业级的层次就不能一点点优化，而是要做一个大的架构升级，提高兼容性，扩展性，并在易用性上下功夫。因此准备设计并实现了本次1.2.2版本的组件化架构升级的版本。

.png&originHeight=341&originWidth=835&originalType=binary&ratio=1&s

一、传统架构下的Service1.1 SSH时代到目前为止还好，曾经用过SSH框架，那时候不懂分层，前后端还不分离。当然，走出校园之后SSH就没有碰过了。在SSH中使用struts action做控制层路由，hibernate做持久化。spring 做bean容器，最后的业务就是在一个项目工程中由struts action类到service bean然后到hibernate dao就可以了。1.2 MVC时代在MVC框架思想中MVC基本上代表了前后端之间的桥梁，服务层依然在幕后操作。但是mybati

一、背景目前低代码生成领域非常火爆，而且市场价值在逐步上升，很多巨头都在重金投入。低代码的出现意味着程序员可以从大量重复低效的劳动中脱离出来，同时可以更好更快的支持业务解决实际问题，极大的提高了交付价值的效率。那么在DDD中实际上也有一些人尝试使用低代码的方式进行建模，意图将建模过程程序化，自动化，通过模板或者预设脚本得到建模结果。本章内容则重点讨论DDD下的代码文档生成的意义，以及这种思路将带给我们什么启示。二、观点2.1 观点1–手动构建很多研究DDD的人都会遇到这个问题–是否使用低代码来降低建

一、背景在之前的文章中已经介绍了DDD相关的概念模式，DDD相关的业务技术架构，但是我们还没有找到一个核心的抓手去实践DDD。DDD的一个核心本质就是对业务建模，或者领域建模。说的很简单，但是做好确实很难，一个需求过来意淫几个实体对象就差不多解决了。深入看，全局看只在脑海中进行的建模实际上并不一定正确和稳定。因此我们需要找到正确的方法帮助对业务领域进行分析，得到建模结构，共享建模成果。二、四色建模法2.1 起源&概念&要素关于四色建模的概念我们可与追溯到90年代，起源于四色原型。四色

一、通用语言模式回顾1.1 通用语言模式（UBIQUITOUS LANGUAGE）通用语言有时也叫统一语言，但是这里我们叫它通用语言。摘录：UBIQUITOUS LANGUAGE（通用语言）的词汇包括类和主要操作的名称。语言中的术语，有些用来讨论模型中已经明确的规则，还有一些则来自施加于模型上的高级组织原则。​1.2 注意事项将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言。在画图、写东西，特别是讲话时也要使用这种语言。通过尝试不同的表示方法（它们反映了备选模型）来消除

一、背景在学DDD的时候我首先看的是《领域驱动设计-软件核心复杂性应对之道》，这本书里记录了很多概念，方法，思想，策略，模式等。整体读下来非常费劲但是收获也不小，如何转化为自己的能力就需要深入揣摩了。很多人觉得DDD门槛很高，或者DDD相关的概念，落地都比较杂，看得令人眼花缭乱，从网上找资料也很不全，不成体系，大部分都是别人一知半解的二次咀嚼思考的产物。因此DDD在很多工程师的眼里就像雾里看花一样，这里我通过这本书简单总结DDD里常见的概念，方法，思想，策略，以及本书没有提到的一些模式。二、模式介绍2

总纲图1![统一语言与模型驱动.png](https://img-blog.csdnimg.cn/img_convert/f8ebcb064e29899ec1ddbec4760bc869.png#height=970&id=STaKC&margin=[object Object]&name=统一语言与模型驱动.png&originHeight=970&originWidth=788&originalType=binary&ratio=1&si

一、背景最近没有再更新DDD相关的技术文章了，因为到了实战环节需要大量的代码demo，由于精力和时间有限，因此便希望借助代码生成来解决一些模板化的工作内容。之前已经在代码生成领域做了一些尝试，这里便希望花一些时间专门做几次迭代来满足DDD项目工程实战的问题。二、需求2.1 支持dubbo框架的代码生成需要生成的代码元素包括facade,impl,dto,service,serviceimpl,bo,do,convert,mapper,mapperxml2.2 支持基于plantUML类图的代码生成

一、功能描述基于nacos管理配置服务，这里借助starter机制与nacos,mysql一起配合管理非核心业务的配置类数据记录，基于json存储，简化业务配置类数据的管理。二、实现原理通过自定义注解将实体数据与nacos配置数据进行绑定动态与nacos进行交互，并解析数据，通过接口访问。2.1 配置说明nacos: #:存储于数据库中的配置数据 datajson: #:扫描配置的枚举entity模型 entitypath: com.coderman.commo

一、背景&痛点1.1 背景我在建设一个租房平台，进行基于租房业务的架构实践。在写业务代码的时候发现我需要一个ID生成器用于生成各种ID和单据编号信息。上篇已经说到我找到了一个比较中意的开源项目，并且已经进行了本地化搭建，相对顺利的看到了效果。1.2 痛点简单进行尝鲜之后便开始了下一步操作，由于租房业务架构的springboot/cloud版本跟id-generator的版本不一样，同时不支持nacos服务注册，因此这里需要进行改造，或者使其支持nacos注册中心，但是支持的过程并不顺

一、背景我正在建设一个租房平台，进行基于租房业务的架构实践。我尝试着按照不同领域创建了几个微服务，写了一些接口，准备模拟真正的IT企业开发环境，但是接口多了难免有变更，维护成本，目前一个人的话维护接口文档确实很费时间，无法投入到更多架构，服务设计落地上。因此需要有一个文档管理平台，来管理不同微服务的接口描述，便于后面多人开发的时候提供基础文档。二、文档管理选型2.1 方案1-自研当时遇到接口文档管理瓶颈之后，想着可以借用之前自己捣鼓的文档管理工具代码进行继续开发和迭代，但是也无异于从头搞一套

一、背景&需求1.1 背景我在公司负责的一个交易核心项目中，项目架构师使用了plantUML进行了表结构e-r图的构建。我非常好奇，因为之前画e-r图都是使用别的软件进行构建的。另外一方面我的业余项目中也需要构建e-r图，但是我不想为每个项目模块去花时间手动构建e-r图。1.2 需求基于已有表结构通过Java api构建plantUML文件 idea安装支持plantUML文件渲染的插件 自动识别表间关系，生成e-r图二、设计方案&实现2.1 方案描述基于mys

一、背景我正在建设一个租房平台，进行基于租房业务的架构实践。在实践过程中发现作为开发人员缺乏大规模微服务，大数据量实战的经验，自己独立捣鼓的话往往无法掌控全局，不能很好的获取实战经验，而如今各个培训机构割韭菜非常多，把架构设计等主题炒的非常热，但是作为中级，初级人员想进行微服务架构设计实战，大数据量应用往往门槛偏高。我经过两个多月的业务实战发现我也陷入其中，在业务应用和大规模微服务实战的过程中缺乏很多基础服务能力，导致业务架构无法快速落地。当前就我一个人在持续投入，进度和效率非常低，因此尽早通过一套基础

一、背景我正在建设一个租房平台，进行基于租房业务的架构实践。微服务选型使用的spring cloud体系，因此需要考虑服务注册和服务治理的问题，由于spring cloud体系中的一些组件都在闭源，因此选取了当前比较合适也比较流行的Nacos注册中心，同时也提供了配置管理的功能。二、nacos版本现在的Nacos已经发展到了2.0了，但是不是稳定版，当前不建议部署到生产环境，比较稳定的是1.4.0，笔者在进行技术选型的时候选取的是1.3.1版本，因此这里主要介绍1.3.1版本的windows版本

本篇文章算是企业服务业务系统的第三篇文章，上一篇选取了几个重量级的企业办公应用系统，其业务复杂度也非常高，本篇则是企业服务业务系统-业务模型梳理的最后一篇文章，本篇将讲述一些业务不是很复杂但是也可以极大提高企业办公效率的一些系统。工单系统1.业务模型申请人，DBA工单，运维工单，业务工单，审批人，操作人（DBA，运维，产品经理，RD）, DBA工单（新数据库申请，DDL操作申请，DML申请，数据库下线，数据导出申请）;OP运维工单（域名申请，集群扩容，机器升配，降配，集群下线，域名回收）;业务工单.

本篇文章算是企业服务业务系统的第二篇文章，上一篇选取了4个系统作为基本业务系统的基础服务功能，有了基础服务，之后的业务系统开展建设起来会方便很多。本篇文章和后面一篇文章则会基于上一篇文章中提到的系统做业务上的系统开发，这里将会介绍一些企业级的办公应用系统。招聘系统1.业务模型简历库，个人信息，简历信息，职位信息，招聘人，应聘人，内推奖招聘流程：简历投递，简历内推，简历审核，约面试走面试流程，面试评价，面试通过，发送offer,入职确认2.业务功能简历录入，简历解析（个人信息，工作经历，教育经.

本篇文章算是企业服务架构演进之路的番外篇吧，之前的7篇文章通过流水账的形式叙述了企业信息系统的建设技术选型和迭代演进的过程。但是没有一些业务沉淀和业务模型相关的积累，技术总是相似的那么有了业务模型，业务流程和功能则会更加贴切一些。因此打算写三篇文章叙述我在企业信息部门中参与开发或者维护过的一些内部业务系统，总共会有超过10个系统的介绍，分别涉及到不同的企业办公，企业运营的子领域，欢迎关注。hr系统1.业务模型员工,用户账号;员工子信息（教育经历，工作经历，薪资福利信息，员工职级&岗位信息，.

本篇是企业服务架构演进系列的第七篇，本篇将讨论一些令广大软件开发者深有感触的一些关于项目重构，项目重建等相关话题，并通过几个切身经历过和使用过的一些系统case来阐述一些更深刻的问题。这些话题引申出来其实是有些严肃的，这深刻的影响到了企业发展的效率，包括人力投入，时间投入，运维成本投入等。很多行业最忌讳的一个词就是返工，虽然很刺耳，但是在重构，重建的包装里面其本质上来说就是没有做好，低效。企业服务架构演进-引言企业服务架构演进-单体架构的变迁企业服务架构演进-从jquery到vue的工程实践企.

本篇是企业服务架构演进系列的第六篇，本篇我打算从另外一个角度去说一下企业服务架构演进的过程中我个人的一些积累。我从正式工作的第二年开始有造轮子的想法，然后从最简单最基础的方式去做，慢慢的可以做一些复杂的工具去提高开发效率，提高程序性能等。到19年我几乎每个季度都会寻找一个合适的场景用业余时间去做一些创新性的东西，这些创新虽然不是那么重要，但是对于企业发展来说，这样的方式正是企业竞争力的一种体现。工具类DAOUtils工具类我从16年底开始做电子合同系统，有些列表页面需要开发，比较特别的地方是这些.