平台上和数据有关的类有实体类BO、视图类VO、传输类DTO；传输类又细分为信息类和请求类。 实体类和数据表关联，字段一一对应，不包括无关信息（有平台采用如下策略，在BO类中使用@ Transient 注解标记无关类，本平台禁止这个做法）视图类VO和数据库中视图绑定，只能读，不能写传输类DTO 前台和后台之间、后台服务之间互相调用使用的传输类。传输类不与数据库绑定。再封装jar包时，实体类
介绍本平台设计时，会对同样问题的不同解决方案进行评价。这些评价决定了平台的取舍。取舍之道才是设计的精华。 有不同意见或更好的做法，欢迎前来交流。 配置文件： 配置文件是部署包的一部分，只能分布，如果要改只能逐一登录对应服务器、打开对应部署目录进行配置。所以要遵循如下原则：
先定义两个概念：字典类和字典项。字典类描述字典的性质，例如性别字典、员工类别字典字典项描述具体字典内容，例如男 女 字典管理通常有两种做法：1个字典一张表 2一张表记录所有字典项信息。千里马平台毫不犹豫采用方法2，因为平台的代码是允许自定义的字典管理为统一管理，单做服务独立出来。 字典项目有如下属性：ID： 数据库里对应数据存储的是字典项目的ID代码： 代码是给人看的，例如导入
首先需要知道一些约束：1） 平台面向的客户是中型以上组织，尤其是超大型组织。2） 平台支撑所有应用，ALL IN ONE。一个组织未来只有一个系统。3） 必须支持国际化。4） 一下子替换所有应用是不切实际的，可以对接易构系统，然后逐步替换。5） 应用是不同厂商开发的。6） 平台要解决开发、运维、监控等多方面问题。 整个平台，用户和权限体系是统一的。用户分两种，实用户和虚用户。实用户是真实
一个大型集团的核心系统能不能替换？华为完成全球88个子公司MetaERP系统切换。答案是可行。反观超大型央企某油，年年花巨额资金交sap的服务·费，这么多年下来交出的海量资金足够研发几套MeatERP了。是国内技术不行吗？当然不是，在操作系统层面，我们的确不足。但在应用领域，国内技术不仅不差，反倒因为后发优势，技术更先进。业务层面更不是问题了，使用系统多年，怎么构建、使用、维护系统都是熟的不能再熟
现在混合系统招标越来越多，靠集成、靠做接口拉通不是优势了。财务系统 我们不占优人力系统 我们也没有绝对优势但是我们的财务、人力是一体的，共享一套权限体系、界面风格一直、数据天然拉通；更绝的是，我们还有OA，还有… 并且这些都是同一个平台上的应用千里马平台就是要构造这样的生态圈，给每一个应用弯道超车的机会。我自己不占优势，但我兄弟多啊。而且由于都是中小企业，我们还有价格优势。甲方有整合的趋势，我们有
总结来讲： 平台+应用是信息化的发展方向。 平台可以共建共享，不以盈利为目的，只为树立大旗。 各成员企业在应用上发挥各自特长。 这些应用是互联互通的。 &nb
千里马平台通过集成框架、管理各类资源来降低重复代码、提高代码复用率，从而实现低代码平台的目标。从效果上讲，千里马平台是低代码平台：千里马平台又不是市场上说的低代码平台没有功能表单定义：千里马平台上前端功能界面是基于ElmentUI组件，程序员编码一个复杂界面实质上不费事，真正花功夫的是界面上的业务逻辑。千里马的流程管理功能中可以定义审批界面，但这个是实施配置，不是开发，也仅仅适用于做审批界面。真正
中国的中小软件开发企业多如牛毛，生存状态大多堪忧。我敢说，每一个存活5年以上的中小软件开发企业，必有至少1个技术大牛。这些大牛放到大公司也是顶尖的存在。也就是中小企业的软件水平并不比所谓大公司差，但是很难拿到单，尤其是大单。其实往往很多大单也是这些中小企业在做（大公司出面然后外包给中小企业）。究其原因，还在于甲方出于安全考虑，不敢将单子直接给中小企业。大公司如果做砸了（其实做砸不在少数），没有太多
干了近30年企业信息化，自己感觉一直是低水平重复。做项目中，使用了大量国外开源的资源。这些开源资源支撑了国内很多中小企业。其实国内很多大公司的所谓原创、所谓国产化，也一样是在开源资源上包了层自己的外壳。所以一直想做点什么。“中台”可以说是中国原创的思想，本可以发扬光大，但是短短几年，就跌落神坛：“中台之父”阿里巴巴大砍中台，中台还有未来吗？中台究竟被谁搞死了？
总结前面所述，我们来整体介绍千里马平台。先看看几个对标平台的定义：用友商业创新平台 YonBIP (Yonyou Business Innovation Platform)：是用友采用新一代信息技术，按照云原生、元数据驱动、中台化和数用分离的架构设计， 涵盖平台服务、应用服务、业务服务与数据服务等形态，集工具、能力和资源服务为一体，服务企业与产业商业创新的平台型、生态化的云服务群。企业级分布式应用
千里马平台的核心是微服务架构。微服务架构有很多种，我们锁定springCloud。服务注册与发现锁定nacos，网关为spring gateway。选型曾经花了很多时间，做了很多比较，我认为这是目前最优组合。不选用这套架构的同学们可以转学了，大家不是一条道上的。版本选择也是个头痛问题，有关版本的问题可见版本说明千里马架构当前选择版本如下：<spring.boot.version>2.3
停更了几天，先去解决吃饭问题。国内原创的东西比较少，个人觉得很大程度上是因为没钱没闲。当然急功近利的思想相对比较严重也是个问题。例如meta一开源，国内就出了一堆所谓原创平台。又例如我们号称的国产数据库很多内核其实是开源。坦诚讲，千里马平台也是基于开源资源的，所以也会开源。 进入正题。首先再次强调，平台是平台，应用是应用，这里讨论的是平台特性，
开宗名义，我们讲的中台系统和中台系统上的应用系统是两回事。很多人把这两者混在一起，讲不清理还乱。中台系统不提供任何业务功能，两者是可以分离的。甲方建设好中台系统后，可以请任意第三方开发其上的应用，可以升级、替换。Tomcat这种业界都定义为中间件，中台系统就是类似这样的角色，只不过更复杂，更庞大。中台系统的作用就是支撑应用运行，提供互相调用的机制，定义一些必要的规范。这样高度聚焦后，中台建设才能有
谈中台前，先说下千里马平台的价值观。价值观都不同，再争论好坏没有意义。我一向推崇大道至简。葵花宝典的核心秘密只有八个字“欲练此功,挥刀自宫”，但是还不够简单。“欲练此功”可以去掉；“挥刀”其实也不是关键，“挥剑”也一样可以，狠人甚至采用硬拽。“自”也不是关键，“他宫”效果也不会差。所以核心非常简单就是“宫”。关于中台的争论，大家很多都是偏离了本源，热火朝天的讨论应该挥剑还是挥刀；讨论是一刀两段好，
中台概念的来源中台概念，起源于阿里高管集体考察世界上最成功的手游公司Supercell的经历。Supercell有个独门绝技，就是他们凭借多年的游戏开发经验，梳理出了一套通用的游戏开发素材、通用算法，依托这些基础工作形成了强大的快速开发能力、得以快速满足市场需求。Supercell用不到200名员工每年可以创造15亿美元利润。通过这次考察，结合自身实践，阿里提出了“大中台、小前台”的企业战略。建立
接下来进行系统设计。 首先系统内需要很多审批流程：立项审批、招投标审批、合同审批。这本是OA的活。在项目管理系统中实现也不是问题，无非是开发点功能，现在市面上项目管理系统就是这样的。但是你想过领导的感受吗？都这么做，他得登录多个系统，按个审批。 项目立项需要专家评审，招投标需要专家评审。除此外其他业务，例如职称评审等也
登录需要记录日志，这个功能很简单，最一般的开发人员都能做。早期是拼SQL语句，自己insert。现在基本上是通过ORM，创建个实例，调用对应的保存方法即可。再扩展一下来看，日志细分为系统运行日志，一般是文件方式存储，记录系统级别的事件，例如程序员最“喜闻乐见”的空指针异常；操作日志，即什么人干了什么事；数据日志，即什么数据从什么变成了什么；流程日志，记录1个过程的演变过程。
最近要为客户开发一套项目管理系统，业务功能就是各部门报项目，然后审批，然后招投标，然后签合同，然后施工管理，然后验收，然后入固定资产，最后项目评价，over。业务场景不复杂，自然投资也不多。我们自己之前也有类似系统，改改就可以交差。之前多年来一直都是这么干的，没觉得有什么不妥。现在再仔细想想还是有很多需要探讨的地方，从这些地方就可以理解千里马平台的技术思路。千里马的技术路线之前也发布了，只所以先发
信息系统架构演变
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
