精华内容
下载资源
问答
  • 2018-09-04 20:32:07

    不同的项目有不同的功能,不同的功能需要不同的实现,实现这些核心功能的代码就叫业务逻辑
    比如让你实现一个功能,给你两个数,让你获取它的和,你所写的如何才能获得任意给定的两个数的和,这个程序实现过程即可成为业务逻辑处理。

     

     

     

    “一个人了解的业务逻辑越多越细,他就是越好的需求分析师。”

    难题:什么是业务逻辑
     

    业务是指一个实体单元向另一个实体单元提供的服务。
    逻辑是指根据已有的信息推出合理的结论的规律。


    业务逻辑是指一个实体单元为了向另一个实体单元提供服务,应该具备的规则与流程。

    就像你家的规矩–“吃饭前必须洗手”“有客人来要起立”“睡觉前各自说晚安”-就是业务逻辑的生活化实例。


    在软件系统架构中,软件一般分为三个层次:表示层、业务逻辑层和数据访问层:

    • 表示层:负责界面和交互;
    • 业务逻辑层:负责定义业务逻辑(规则、工作流、数据完整性等),接收来自表示层的数据请求,逻辑判断后,向数据访问层提交请求,并传递数据访问结果,业务逻辑层实际上是一个中间件,起着承上启下的重要作用;
    • 数据访问层:负责数据读取。

     

    业务逻辑的内容包括四个部分:

    • 领域实体:定义了业务中的对象,对象有属性和行为;
    • 业务规则:定义了需要完成一个动作,必须满足的条件;
    • 数据完整性:某些数据不可少;
    • 工作流:定义了领域实体之间的交互关系。

     

    以大毛网购裤子为例

    • 领域实体:大毛、资金账户、订单、裤子、发货单
    • 业务规则:大毛点击购买就会生成订单,但必须付了钱,才会发货,生成发货单。
    • 数据完整性:淘宝网下订单必须登录账号,没有账号就不能成功购买。
    • 工作流:搜索裤子-找到合意裤子-下单购买-付账-收货。

    业务逻辑:搜索“裤子”-找到合意裤子-下单-必须登录账号-结算-付账-收货。

    当当必须登录账号才能下单成功,亚马逊就不需要,今天发现淘宝也不需要登录账号就能购买商品了,所以每个网站的规则的不同,就形成了不同的业务逻辑,业务逻辑不仅仅包括规则,还包括实体、数据完整性、工作流。如图:

    业务逻辑图

     

    业务逻辑图

    业务逻辑也需要画图,叫做业务逻辑图,它跟业务流程图有什么区别呢?
    业务流(工作流)是业务逻辑的一部分,它定义了对象之间的交互关系,但不涉及到规则的制定,数据的完整性方面。
    其实,我们平常画的业务流程图多数是业务逻辑图。
     

     

    所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展

    分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展

    和分配资源。

     

    所谓的三层开发就是将系统的整个业务应用划分为表示层,业务逻辑层和数据访问层,这样有利于系统的开发、维护、部署和扩展。

    分层是为了实现“高内聚,低耦合”。采用“分而治之”的思想,把问题划分开来各个解决,易于控制,延展和分配资源。

    业务逻辑层负责系统领域业务的处理,负责逻辑性数据的生成、处理及转换。对所输入的逻辑性数据的正确性及有效性负责,但对输出的逻辑性数 据及用户性数据的正确性不负责,对数据的呈现样式不负责。


    JavaEE三层架构MVC,把视图控制器模型分开来

    那么在这里业务逻辑就是M。

    但是什么样的算是业务逻辑如:上传一个文件,上传代码算是一个业务逻辑吗?

    数据库操作增加时需要判断,和一些其它这算业务逻辑吗?(我觉得算)

    但是hibernate又提供了一个离线查询对象(DetachedCriter),提供这个接口的意思我想是在外面处理业务逻辑。

    但是三层架构不是独立的吗?互相不干涉吗?在service层出现sql,hql,criter不是又把dao与service连在一起了吗?

    DTO(VO),POJO,BO这些是什么,POJO对应数据库,BO对应业务逻辑,DTO对应页面的传输与显示。

     


           业务逻辑就是处理数据的逻辑啦。一般后台代码也分三层 action(controller) service DAO (这里的三层不是MVC)

     

            比如 我得到用户名 但是在存入数据库的时候 用户名字段应该是前台的用户名加上当前日期拼成的字符串

    action或者controller层是第一层 一般是用来及接受数据并且做数据的非空啊 格式是否正确的验证

      如用户名是否为空 是不是安全字符串之类的

    service层一般是用来做一个业务逻辑的实现

      这时候 userName = userName + new Date();

     

           DAO层 就是与数据库交互层啦

      也就是读写数据库 将逻辑层得到的新的userName插入到数据库

     

          MVC和三层架构并没有可比性三层架构是指将程序分为数据访问、业务处理、界面三个层次,是软甲整体架构MVC是仅仅是界面架构,也就是它其实只是三层架构的界面部分,M是指实体模型或者实体模型的一个代理,而非领域模型,C是指控制器,仅仅是做转向,不应该包含任何业务逻辑,V就是视图了。至于那些个什么什么O,都是实体在不同层的映射。另外值得一提的是,MVC在一些小的程序中也经常被当做软件整体架构,那个时候M往往就是实体模型了,但是这种时候,V就对M产生了直接引用,也就是界面对实体产生依赖,这是很不好的(但小程序问题不大),此时可以尝试使用MVP模式解耦。至于业务,看你怎么定义领域模型了,一般像上传文件这种操作并不会牵扯企业的业务,那就不应该当做一个业务,但如果这个上传是在工作流或者一些特殊处理中,则有可能上升到业务。怎么做,要看具体问题。

    转自原文:https://blog.csdn.net/u010098331/article/details/51700777

    更多相关内容
  • 按:业务架构有三化——配置化、产品化、自动化,配置化解决业务系统灵活性、动态可变的问题,产品化解决工具复用提效的问题,自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置...

    按:业务架构有三化——配置化、产品化、自动化,配置化解决业务系统灵活性、动态可变的问题,产品化解决工具复用提效的问题,自动化让机器工作、解决人力成本问题。本文来自百度刘志伟、韩炳涛两位同学对百万行配置化经验的分享,具备有一定总结的抽象性。

     

    背景

    互联网软件市场是一个快速变化的市场,优秀的服务层出不穷,所以互联网软件公司需要快速推出服务抢占市场、并且能够快速响应用户的需求,否则就面临被淘汰的命运。这跟达尔文主义的观点是一致的:

    It is not the strongest species that survive, nor the most intelligent, but the ones most responsive to change.

    大型且成熟的互联网产品为了能保持适应快速变化的市场则尤其困难,比如百度某广告系统由百万级的 C++/JAVA 代码构成,上百人工作在上面,并且每天进行着大量的业务需求迭代。由于系统演化多年,代码实现常常耦合,代码上的迭代容易引发问题,相应的回滚处理都比较复杂。静态代码构成的大型系统在编译、重型的测试上都耗费很多时间。系统不断重启升级,也影响了对外提供服务,甚至会影响收入。为了能够使复杂系统仍然能快速应对变化,我们进行了一系列服务化以及配置化的实践。

    从14年逐渐兴起的微服务架构是作为面向服务架构的一个特定方法,强调的是小而独立的服务,根本上还是对从领域里抽象成服务并进行管理。从快速应对变化的视角上看,微服务的技术异构性使得我们在面临不同的问题的时候,能够选择最适合的技术进行快速解决,以及能对服务进行组合,从而快速实现针对不同的客户提供不同的功能。除此之外,微服务在弹性、扩展性上等等都有很好的优势。此类的文章已经比较多,本文重点讲述配置化架构的实践。

    什么是配置化架构

    在软件系统中的配置通常指的是软件系统中的对象、对象属性、数据等,借助独立于软件系统的标准数据格式语言,比如xml、json、yaml,进行表达,从而能够在只改变标准数据格式语言且不改变软件系统本身功能的情况下,就能改变系统行为的方式。

    应用配置的场景非常多,比如在百度用C++开发的搜索引擎控制模块,把用户查询的关键字通过消息,发送到后端存储服务上进行检索。查询消息的超时时间,以及消息在超时后需要重新尝试的次数,都是参数类的数值。我们可以通过C++代码里直接用常量表示,也可以通过配置的方式指定。他们的不同点是,一旦数值发生变化,静态代码需要做重新编译、重启升级、往往还需要通过繁重的测试以及很多的人工操作。配置为快速变更提供了可能,不需要做编译,也可以通过动态加载的方式避免系统的重启,甚至如果变更是安全可控的,繁重的测试以及很多人工操作都可以节省。再比如开关,借助于Google 的 Gflag,我们可以在运行时灵活的控制某个功能的关闭和开启。

    架构有着非常多的定义,Roy Thomas Fielding 在 < architectural styles and the design of network-based software architectures > 把软件架构定义一种架构元素(组件、连接器、数据)的配置表示。这里配置的语义变得更宽泛了,已经不再是指单纯的标准数据格式语言(xml, json, yaml)类的配置,而是一种能够描述架构的语言。使用配置更宽泛的语义,配置化架构定义如下:

    配置化架构是指可配置的方式构建软件的方法。它是在领域建模的基础上,以配置表述业务,以配置组织架构元素(服务、组件、数据),并对配置进行规范化、自动化的管理。

    配置化架构的基础是对领域的抽象以及软件系统的高度的自动化。

    优缺点

    配置化架构的开发方式,相对于代码开发,无论是在服务的级别,还是在组件内部的级别,甚至是内部参数,都可以在不对软件功能进行变更的情况下,就能实现软件系统内的这些元素进行调整。配置化架构的优势是在较低的变更成本下,实现快速的调整软件系统。

    然而,配置的校验往往是依赖于标准数据格式(xml、json、yaml)的解释器或者额外的 schema 工具,相比于编程语言,还是缺乏更严格语义上的校验保证;而且目前往往对于配置的编辑也缺乏业务级的测试,这些都可能引入bug。所以在实现配置化架构的时候,我们需要在校验、自动化测试、以及基础设施上做很多工作;而且实现配置化架构的时候,有时候还需要借助领域特定语言,这些都引入了额外的开发、学习以及维护成本。

    平衡优缺点,建议还是从需求变更的频率的角度去考虑,在需要快速调整软件系统的情况下,实现快速以及高度自动化的配置化架构是非常有价值的。

    技术基础

    和微服务架构一样,配置化架构也不是被发明出来的,而是从复杂软件系统总结出的趋势或模式。它依赖于主要技术如下:

    • 对于领域业务进行合理的抽象和划分。为了能够进行配置化管理,业务代码必须要进行业务领域的抽象和划分,需要面向对象以及领域驱动开发的技术。

    • 为了能够对业务进行刻画,我们需要借助于领域特定语言(Domain Specific Language)。

    • 配置化架构能够进行快速调整的基础是完备的自动化基础设施。传统的周期性发布无法满足持续、快速调整的需求,借助于 DevOps 的方法论,配置化的开发做到配置的持续发布。

    架构评估

    几年以前欧洲的几个大学和几家软件公司经过多年在实践中总结,从商业、软件架构、开发流程、组织角度(BAPO)提出 FEF 软件开发的评估体系,在软件架构上,配置化成为软件架构的最高级别。配置化架构是架构努力的方向。


    实现模式

    本章是在实践配置化架构时候,针对通用问题及其方案的总结,为在实践配置化架构的时候,遇到同类的问题提供实现参考。本篇文章采用了分类的方式进行总结,「风格」指的是从领域业务模型的角度上看,用配置去实现业务的三类方式;「语言」指的是在采用何种语言去实现配置化;而「基础设施」指的是基本的配置管理、发布流程等。虽然采用了分开论述的方式,但是实际上,应用配置化架构去解决问题的时候,是综合应用「风格」、「语言」以及「基础设施」的结果。这会在案例部分展现解决问题的全貌。

    本篇文章介绍的是几类概要的实践,详细的方案以及更多的实现模式会通过后续文章持续发布。

    • 风格

      • 参数式

      • 模型式

      • 脚本式

    • 语言

      • 标准数据格式

      • 领域特定语言

      • 嵌入脚本语言

      • 配置自动生成

      • 可视化

    • 基础设施

      • 配置管理

      • 持续发布

    实现模式:风格

    配置化架构的基础之一是以配置对业务进行抽象上描述,从这个角度看,配置化架构可以归纳为三类风格,参数式、模型式以及脚本式。

    参数式

    参数式的配置是表达业务的最简单的方式,也是最常见的一种形式。比如对于功能的开关、阈值、基础组件参数值(比如消息的超时时间)等等,通常采用简单的 K-V 形式进行表达。标准数据格式语言,如 XML,JSON,YAML 等等都是支持参数式配置常用的工具。

    模型式

    模型式配置化架构解决的问题相比于参数式更为复杂,它往往需要对领域业务进行建模,才能通过配置进行表达。

    比如,当我们希望能灵活的对业务进行组合,要做到这样的事,我们首先需要对不同的业务抽象成不同的组件,分清楚哪些是业务组件要做的事,哪些是组件之间的关系。服务编排依靠内聚度与耦合度,强调服务的嵌套、松耦合性。这里说的组件拓扑指的的是将表达业务的组件和表达组件之间的关系进行分离。然后我们可以用配置表达组件的属性,以及组件拓扑,好处是能快速调整组件的属性以及关系,进而能灵活的组合不同的服务、组件完成不同的业务。

    以配置表达的拓扑关系,为了满足更多特定的业务,往往需要借助于领域特定语言,增加丰富的语义。

    以离线的数据处理为例,期望能做到特征抽取,特征合并,用户属性管理等等业务进行组合,对于不同的输入请求,需要完成的业务不同。所以这些业务代码,被抽象成组件:负责特征提取的组件、负责合并特征的组件、负责用户属性的组件等等。每个组件都有自己独立的属性配置,不同组件的以树状关系进行组合。

    在应用领域特定语言的基础上,把配置具备了更丰富的语义,能表达引用、默认值、覆盖等语义后,系统可以按照拓扑树的结构,通过反射的方式初始化内存中也是树结构的组件,每个组件会加载自己的配置。这种配置化的方式可以快速调整组件的属性,也可以快速调整组件的组合方式,达到灵活的表达业务的效果。


    脚本式

    当业务不属于参数式和模型式的时候,比如业务代码各式各样,无法用抽象的配置语言统一表达,我们可以通过脚本语言实现配置化。一般来说都是指在静态语言里嵌入了动态语言。

    以展示广告为例,UI 需要在不同的请求处理地方进行实验(实验是通过使得不同的人看到不同的展示广告,根据效果决策出更好的广告展现),然而实验的增加、变更、删除都是极其频繁的变更。静态代码在处理实验代码的时候变得很庞杂,并且也不能快速进行实验的变更。因此我们使用了 luajit ,通过 protocol buffer 和 UI 模块进行交互,完成实验的逻辑。


    实现模式:语言

    在明确了哪类风格的配置化架构后,我们需要去选择合适的配置语言去解决相应的问题。比如常见的是采用标准数据格式语言,比如 xml, json 或者 yaml 等。或者采用可视化的界面进行配置的编辑。本文介绍使用领域特定语言以及代码生成配置。

    领域特定语言

    当我们希望能以配置表达更多的需求,比如表达逻辑语义,常见的配置使用方式就无法满足了。我们需要在配置上构建更多的语义来表达业务。

    领域特定语言(DSL)是指针对某一个特定的领域,设计实现出具有受限表达性的语言。DSL 的优势在于,在特定领域下,更能直观、自然的去描述业务的方法。

    我们可以创造出新的语言表达需求。但有时候我们也会在标准 yaml、json、xml 等语法上,针对特定的需求,进行封装,使配置表达更多的业务。业界有很多这样的案例,比如 IBM 的 DB2 JSON Library 给 JSON 增加了 query 语义。

    仍然以实验为例,为了使得实验本身的信息,尤其是 condition、action 进行直观的表达、灵活的组合以及快速修改,避免了之前用 C++ 代码更新的方式。给 yaml 增加了相应的表达语义。

    4955:

        OTHER_INFOMATION: description

        CONDITIONS:

            - $ SIGN(user.domain) in TEXT_FILE('domain_blacklist.txt')

            - $ user.is_lu == 1

        ACTIONS:

            - $ pb.dcpub.noad = se_lib.NOAD_REASON.DROP_FLOW

            - $ ->FLAG_get_lu2_from_prediction_service = 1

     

    配置自动生成

    采用配置化的方式进行开发,配置规模会逐渐变得很大。我们需要确保编写与维护配置的成本要比编辑代码更简洁。虽然说配置的更新相比于代码更轻量级,然而代码相比配置,具备更好的模块化以及可重用性,使得代码在大规模的情况下仍然可以得到很好的管理。

    结合配置与代码的各自优势,我们可以把配置当成代码进行管理:以编程语言(比如 Python)生成配置,实际上配置变成方便程序识别的中间产物,RD 管理的是生成配置的代码,利用代码的模块化以及代码重用性,避免配置的维护成本更高。

    用户基于定义好的、可复用的对象以及 Python 函数,编写自己的 Python 函数,填写自己特定的配置值,完成后调用 compiler 生成配置。


    案例

    在离线任务部署的时候,每个部署任务都需要从一份配置模板生成自己特定的配置。配置的模板通过 Thrift 对象以及 Python 函数进行定义。下面是以这种方式生成一个组件的例子。


    实现模式:基础设施

    配置管理

    大部分的配置并不需要额外的管理操作,配置文件存储在 SVN/GIT 等版本管理工具上,配置内容也都不需要额外的逻辑控制,我们可以称这种简单的情况为「最简单的配置管理」。然而在配置规模变大或者需要对配置内容进行控制的时候,需要就更好的配置存储管理。

    从整体上考虑配置管理的功能时候就会发现,可以按经典的三层架构模式去理解配置管理,配置管理需要:用户交互层、业务逻辑控制层以及存储层(数据访问层)。

    「最简单的配置管理」是情况是:用户交互层提供给用户进行交互的是纯配置文件而不是通常理解上的可视化界面,并且由于不需要额外的配置内容逻辑控制,所以没有业务逻辑控制层。但它仍然是一种配置管理。当我们需要更多的功能时候,我们可以在「最简单的配置管理」上进行增加。

    这是在展示广告系统构架的三层架构配置管理,主要的内容是:

    • 提供 web UI,让用户可视化的编辑配置内容,与查看各种统计等功能。UI 到后端的逻辑控制层采用 restful API 进行交互

    • 在配置的逻辑控制层,我们对配置的内容进行基本校验、统计、存储等逻辑控制功能

    • 在后端存储,由于要复用 SVN/GIT 的版本管理功能、冲突检测合并功能、用户权限控制等功能,并且避免维护独立的Sql类存储服务器的工作量,我们采用 SVN/GIT 作为后端存储管理。


    持续发布

    配置化架构所期望的目标是能快速对软件系统做出调整。然而有时候即便是软件本身的配置能做出快速调整了,但是在传统的长周期发布方式下,除了要进行等待,对于缓存的很多变更,需要更复杂的测试以及一旦出现问题,排查以及回滚都会非常困难,这些情况都导致了不能达到快速变更系统的目的。

    持续发布是配置化架构的一个基础。配置的变更不会缓存、积压起来,而是会触发包括测试、部署的流水,进而发布到线上。即使中间有错误由于变更被拆的很小会被快速定位以及能做到快速回滚。

    这是一个在展示广告系统持续发布的示意图。从存储出发,一旦Jenkins/Hudson 检测到配置的 SVN/GIT 变化,就会触发 Jenkins/Hudson Job 流水线。目前我们的 Job 流水线主要有 2 类,首先要构建配置的 package,然后进行轻量级的自动化测试进行校验。我们甚至可以对配置进行分类,对于特定的的配置变更,比如对于不断调整的参数值,只经过基本的校验就可以直接部署到线上。


    除了百度,我们从 Facebook 的论文了解到,Facebook 可以做到每天升级 2 次代码。但是配置的升级是千次以上。他们的基础也是配置的持续发布。

    总结

    本文总结配置化架构的技术进行了概述,并且总结一些实现上的模式。更多的模式实践,以及应用配置化的案例,会发布在后续的文章中。

     


    =>更多文章请参考《中国互联网业务研发体系架构指南》

    =>更多TOP权威案例及行业标准资料请关注微信公众号:

    公众号:关注更多实时动态
    更多内容关注公众号:软件真理与光
    展开全文
  • 业务中台、数据台、技术台到底是什么

    千次阅读 多人点赞 2021-03-16 13:48:38
    业务中台、数据台、技术台到底是什么?00 台能力总体框架01 业务中台02 数据台数据应用技术发展迅猛数据架构更加灵活数据来源更加多元化,数据格式更加多样化数据智能化应用将会越来越广泛03 技术台1. API...

    作者:大数据DT
    来源:大数据DT

    导读:2015年 阿里巴巴提出“大中台,小前台”的中台战略,通过实施中台战略找到能够快速应对外界变化,整合阿里各种基础能力,高效支撑业务创新的机制。

    阿里巴巴中台战略最早从业务中台数据中台建设开始,采用了双中台的建设模式,

    到后来发展出了移动中台技术中台研发中台等,这些中台的能力综合在一起就构成了阿里巴巴企业级数字化能力。

    传统企业在技术能力、组织架构和商业模式等方面与阿里巴巴存在非常大的差异,在实施中台战略时是否可以照搬阿里巴巴中台建设模式?传统企业中台数字化转型需要提升哪些方面的基本能力呢?

    00 中台能力总体框架

    中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程,最终目标是实现企业级业务能力复用和不同业务板块能力的联通和融合。

    企业级的综合能力,一般包含以下四种:业务能力数据能力技术能力组织能力,如图2-1所示。
    在这里插入图片描述
    ▲图2-1 企业中台数字化转型基本能力框架


    • 业务能力:主要体现为对中台领域模型的构建能力,对领域模型的持续演进能力,企业级业务能力的复用、融合和产品化运营能力,以及快速响应市场的商业模式创新能力。

    • 数据能力:主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力。

    • 技术能力:主要体现为对设备、网络等基础资源的自动化运维和管理能力,对微服务等分布式技术架构体系化的设计、开发和架构演进能力。

    • 组织能力:主要体现为一体化的研发运营能力和敏捷的中台产品化运营能力,还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力。

    这些能力相辅相成,融合在一起为企业中台数字化转型发挥最大效能。接下来,我们一起来看看在不同的领域应该如何实现这些能力。

    01 业务中台

    企业所有能力建设都是服务于前台一线业务的。从这个角度来讲,所有中台应该都可以称为业务中台。但我们所说的业务中台一般是指支持企业线上核心业务的中台

    业务中台承载了企业核心关键业务,是企业的核心业务能力,也是企业数字化转型的重点。

    业务中台的建设目标是:“将可复用的业务能力沉淀到业务中台,实现企业级业务能力复用和各业务板块之间的联通和协同,确保关键业务链路的稳定高效,提升业务创新效能。

    业务中台的主要目标是实现企业级业务能力的复用,所以业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型,将分散在不同渠道和业务场景(例如:互联网应用和传统核心应用)重复建设的业务能力,沉淀到企业级中台业务模型,面向企业所有业务场景和领域,实现能力复用和流程融合。

    图2-2是一个业务中台示例。在业务中台设计时,我们可以将用户管理、订单管理、商品管理和支付等这些通用的能力,通过业务领域边界划分和领域建模,沉淀到用户中心、订单中心、商品中心和支付中心等业务中台,然后基于分布式微服务技术体系完成微服务建设,形成企业级解决方案,面向前台应用提供可复用的业务能力。
    在这里插入图片描述
    ▲图2-2 业务中台示例


    在技术实现上,中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现,可以有效提升业务扩展能力,实现业务能力复用。

    在业务建模上,中台领域建模可以采用领域驱动设计(DDD)方法,通过划分业务限界上下文边界,构建中台领域模型,根据领域模型完成微服务拆分和设计。

    业务中台可以面向前台应用提供基于API接口级的业务服务能力,也可以将领域模型所在的微服务和微前端组合为业务单元,以组件的形式面向前台应用,提供基于微前端的页面级服务能力。

    业务中台建设完成后,前台应用就可以联通和组装各个不同中台业务板块,既提供企业级一体化业务能力支撑,又可以提供灵活的场景化销售能力支撑。

    02 数据中台

    数据中台与业务中台相辅相成,共同支持前台一线业务。

    数据中台除了拥有传统数据平台的统计分析和决策支持功能外,会更多聚焦于为前台一线交易类业务提供智能化的数据服务,支持企业流程智能化、运营智能化、商业模式创新,实现“业务数据化和数据业务化”。

    最近几年,数据应用领域出现了很多新的趋势。数据中台建设模式也随着这些趋势在发生变化,主要体现在以下几点。

    数据应用技术发展迅猛

    第一,数据应用技术发展迅猛。近几年涌现出了大量新的数据应用技术,如NoSQL、NewSQL和分布式数据库等,以及与数据采集、数据存储、数据建模和数据挖掘等大数据相关的技术。这些技术解决业务问题的能力越来越强,但同时也增加了技术实现的复杂度。

    数据架构更加灵活

    第二,数据架构更加灵活。在从单体向微服务架构转型后,企业业务和数据形态也发生了很大的变化,数据架构已经从集中式架构向分布式架构转变。

    数据来源更加多元化,数据格式更加多样化

    第三,数据来源更加多元化,数据格式更加多样化。随着车联网、物联网、LBS和社交媒体等数据的引入,数据来源已从单一的业务数据向复杂的多源数据转变,数据格式也已经从以结构化为主向结构化与非结构化多种模式混合的方向转变。

    数据智能化应用将会越来越广泛

    第四,数据智能化应用将会越来越广泛。在数字新基建的大背景下,未来企业将汇集多种模式下的数据,借助深度学习和人工智能等智能技术,优化业务流程,实现业务流程的智能化,通过用户行为分析提升用户体验,实现精准营销、反欺诈和风险管控,实现数字化和智能化的产品运营以及AIOps等,提升企业数字智能化水平。



    面对复杂的数据领域,如何建设数据中台管理并利用好这些数据?

    这对企业来说是一个非常重要的课题。

    数据中台的大部分数据来源于业务中台,经过数据建模和数据分析等操作后,将加工后的数据,返回业务中台为前台应用提供数据服务,或直接以数据类应用的方式面向前台应用提供API数据服务。

    数据中台一般包括数据采集、数据集成、数据治理、数据应用和数据资产管理,另外还有诸如数据标准和指标建设,以及数据仓库或大数据等技术应用。

    图2-3是2017年阿里云栖大会上的一个数据中台示例。
    在这里插入图片描述
    ▲图2-3 数据中台示例(图参考:2017年阿里云栖大会)


    综上所述,数据中台建设需要做好以下三方面的工作。

    • 一是建立统一的企业级数据标准指标体系,解决数据来源多元化和标准不统一的问题
      企业在统一的数据标准下,规范有序地完成数据采集、数据建模、数据分析、数据集成、数据应用和数据资产管理。

    • 二是建立与企业能力相适应的数据研发、分析、应用和资产管理技术体系
      结合企业自身技术能力和数据应用场景,选择合适的技术体系构建数据中台。

    • 三是构建支持前台一线业务的数据中台
      业务中台微服务化后,虽然提升了应用的高可用能力,但是随着数据和应用的拆分,会形成更多的数据孤岛,会增加应用和数据集成的难度。在业务中台建设的同时,需要同步启动数据中台建设,整合业务中台数据,消除不同业务板块核心业务链条之间的数据孤岛,对外提供统一的一致的数据服务。用“业务+数据”双中台模式,支持业务、数据和流程的融合。

    数据中台投入相对较大,收益周期较长,但会给企业带来巨大的潜在商业价值,也是企业未来数字化运营的重要基础。企业可以根据业务发展需求,制定好阶段性目标,分步骤、有计划地整合好现有数据平台,演进式推进数据中台建设。

    03 技术中台

    业务中台落地时需要有很多的技术组件支撑,这些不同技术领域的技术组件就组成了技术中台。

    业务中台大多采用微服务架构,以保障系统高可用性,有效应对高频海量业务访问场景,所以技术中台会有比较多的微服务相关的技术组件

    一般来说,技术中台会有以下几类关键技术领域的组件,如API网关、前端开发框架、微服务开发框架、微服务治理组件、分布式数据库以及分布式架构下诸如复制、同步等数据处理相关的关键技术组件,如图2-4所示。

    1. API网关

    微服务架构一般采用前后端分离设计,前端页面逻辑和后端微服务业务逻辑独立开发、独立部署,通过网关实现前后端集成。

    前台应用接入中台微服务的技术组件一般是API网关。

    API网关主要包括:鉴权、降级限流、流量分析、负载均衡、服务路由和访问日志等功能

    API网关可以帮助用户,方便地管理微服务API接口,实现安全的前后端分离,实现高效的系统集成和精细的服务监控。

    2. 开发框架

    开发框架主要包括前端开发框架和后端微服务开发框架。基于前、后端开发框架,分别完成前端页面逻辑和后端业务逻辑的开发。

    前端开发框架主要是面向PC端或者移动端应用,用于构建系统表示层,规范前后端交互,降低前端开发成本。
    在这里插入图片描述
    ▲图2-4 技术中台关键技术领域


    微服务开发框架用于构建企业级微服务应用。

    一般具备自动化配置、快速开发、方便调试及部署等特性,提供微服务注册、发现、通信、容错和监控等服务治理基础类库,帮助开发人员快速构建产品级的微服务应用。

    开发框架一般都支持代码自动生成、本地调试和依赖管理等功能

    3. 微服务治理

    微服务治理是在微服务的运行过程中,针对微服务的运行状况采取的动态治理策略,如服务注册、发现、限流、熔断和降级等,以保障微服务能够持续稳定运行

    微服务治理主要应用于微服务运行中的状态监控、微服务运行异常时的治理策略配置等场景,保障微服务在常见异常场景下的自恢复能力。

    微服务治理技术组件一般包括服务注册、服务发现、服务通信、配置中心、服务熔断、容错和微服务监控等组件。

    常见的微服务治理有Dubbo、Spring Cloud和Service Mesh等技术体系

    4. 分布式数据库

    分布式数据库一般都具有较强的数据线性扩展能力,它们大多采用数据多副本机制实现数据库高可用,具有可扩展和低成本等技术优势。

    分布式数据库一般包括三类:交易型分布式数据库分析型分布式数据库交易分析混合型分布式数据库

    • 交易型分布式数据库:用于解决交易型业务的数据库计算能力,它支持数据分库、分片、数据多副本,具有高可用的特性,提供统一的运维界面,具备高性能的交易型业务数据处理能力。主要应用于具有跨区域部署和高可用需求,需支持高并发和高频访问的核心交易类业务场景。

    • 分析型分布式数据库:通过横向扩展能力和并行计算能力,提升数据整体计算能力和吞吐量,支持海量数据的分析。主要应用于大规模结构化数据的统计分析、高性能交互式分析等场景,如数据仓库、数据集市等。

    • 交易分析混合型分布式数据库:通过资源隔离、分时和数据多副本等技术手段,基于不同的数据存储、访问性能和量等需求,使用不同的存储介质和分布式计算引擎,同时满足业务交易和分析需求。主要应用于数据规模大和访问并发量大,需要解决交易型数据同步到分析型数据库时成本高的问题,需要解决数据库入口统一的问题,需要支持高可用和高扩展性等数据处理业务场景。

    5. 数据处理组件

    为了提高应用性能和业务承载能力,降低微服务的耦合度,实现分布式架构下的分布式事务等要求,技术中台还有很多数据处理相关的基础技术组件

    如:分布式缓存、搜索引擎、数据复制、消息中间件和分布式事务等技术组件。

    • 分布式缓存是将高频热点数据集分布于多个内存集群节点,以复制、分发、分区和失效相结合的方式进行维护,解决高并发热点数据访问性能问题,降低后台数据库访问压力,提升系统吞吐能力。
      典型的开源分布式缓存技术组件有Redis。

    • 搜索引擎主要解决大数据量的快速搜索和分析等需求。

      将业务、日志类等不同类型的数据,加载到搜索引擎,提供可扩展和近实时的搜索能力。

    • 数据复制主要解决数据同步需求,实现同构、异构数据库间以及跨数据中心的数据复制,满足数据多级存储、交换和整合需求。

      主要应用于基于表或库的业务数据迁移、业务数据向数据仓库复制等数据迁移场景。

      数据复制技术组件大多采用数据库日志捕获和解析技术,在技术选型时需考虑数据复制技术组件与源端数据库的适配能力。

    • 消息中间件主要适用于数据最终一致性的业务场景,它采用异步化的设计,实现数据同步转异步操作,支持海量异步数据调用,并通过削峰填谷设计提高业务吞吐量和承载能力。

      它被广泛用于微服务之间的数据异步传输、大数据日志采集和流计算等场景。另外,在领域驱动设计的领域事件驱动模型中,消息中间件是实现领域事件数据最终一致性的非常关键的技术组件,可以实现微服务之间的解耦,满足“高内聚,松耦合”设计原则。典型的开源消息中间件有Kafka等。

    分布式事务主要是解决分布式架构下事务一致性的问题。单体应用被拆分成微服务后,原来单体应用大量的内部调用会变成跨微服务访问,业务调用链路中任意一个节点出现问题,都可能造成数据不一致。分布式事务是基于分布式事务模型,保证跨数据库或跨微服务调用场景下的数据一致性。

    分布式事务虽然可以实时保证数据的一致性,但过多的分布式事务设计会导致系统性能下降。

    因此微服务设计时应优先采用基于消息中间件的最终数据一致性机制,尽量避免使用分布式事务。

    技术中台是业务中台建设的关键技术基础。在中台建设过程中,可以根据业务需要不断更新和吸纳新的技术组件,也可以考虑将一些不具有明显业务含义的通用组件(如认证等),通过抽象和标准化设计后纳入技术中台统一管理。

    为了保证业务中台的高性能和稳定性,在技术组件选型时一定要记住:尽可能选用成熟的技术组件。

    展开全文
  • 一文教会你如何写复杂业务代码

    千次阅读 多人点赞 2019-08-05 14:00:17
    结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。 我相信,同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业...

    了解我的人都知道,我一直在致力于应用架构和代码复杂度的治理。

    这两天在看零售通商品域的代码。面对零售通如此复杂的业务场景,如何在架构和代码层面进行应对,是一个新课题。针对该命题,我进行了比较细致的思考和研究。结合实际的业务场景,我沉淀了一套“如何写复杂业务代码”的方法论,在此分享给大家。

    我相信,同样的方法论可以复制到大部分复杂业务场景。

    一个复杂业务的处理过程

    业务背景

    简单的介绍下业务背景,零售通是给线下小店供货的B2B模式,我们希望通过数字化重构传统供应链渠道,提升供应链效率,为新零售助力。阿里在中间是一个平台角色,提供的是Bsbc中的service的功能。

    在商品域,运营会操作一个“上架”动作,上架之后,商品就能在零售通上面对小店进行销售了。是零售通业务非常关键的业务操作之一,因此涉及很多的数据校验和关联操作

    针对上架,一个简化的业务流程如下所示:

    过程分解

    像这么复杂的业务,我想应该没有人会写在一个service方法中吧。一个类解决不了,那就分治吧。

    说实话,能想到分而治之的工程师,已经做的不错了,至少比没有分治思维要好很多。我也见过复杂程度相当的业务,连分解都没有,就是一堆方法和类的堆砌。

    不过,这里存在一个问题:即很多同学过度的依赖工具或是辅助手段来实现分解。比如在我们的商品域中,类似的分解手段至少有3套以上,有自制的流程引擎,有依赖于数据库配置的流程处理:

    本质上来讲,这些辅助手段做的都是一个pipeline的处理流程,没有其它。因此,我建议此处最好保持KISS(Keep It Simple and Stupid),即最好是什么工具都不要用,次之是用一个极简的Pipeline模式,最差是使用像流程引擎这样的重方法

    除非你的应用有极强的流程可视化和编排的诉求,否则我非常不推荐使用流程引擎等工具。第一,它会引入额外的复杂度,特别是那些需要持久化状态的流程引擎;第二,它会割裂代码,导致阅读代码的不顺畅。大胆断言一下,全天下估计80%对流程引擎的使用都是得不偿失的

    回到商品上架的问题,这里问题核心是工具吗?是设计模式带来的代码灵活性吗?显然不是,问题的核心应该是如何分解问题和抽象问题,知道金字塔原理的应该知道,此处,我们可以使用结构化分解将问题解构成一个有层级的金字塔结构:

    按照这种分解写的代码,就像一本书,目录和内容清晰明了。

    以商品上架为例,程序的入口是一个上架命令(OnSaleCommand), 它由三个阶段(Phase)组成。

    @Command
    public class OnSaleNormalItemCmdExe {
    
        @Resource
        private OnSaleContextInitPhase onSaleContextInitPhase;
        @Resource
        private OnSaleDataCheckPhase onSaleDataCheckPhase;
        @Resource
        private OnSaleProcessPhase onSaleProcessPhase;
    
        @Override
        public Response execute(OnSaleNormalItemCmd cmd) {
            
            OnSaleContext onSaleContext = init(cmd);
            
            checkData(onSaleContext);
    
            process(onSaleContext);
    
            return Response.buildSuccess();
        }
    
        private OnSaleContext init(OnSaleNormalItemCmd cmd) {
            return onSaleContextInitPhase.init(cmd);
        }
    
        private void checkData(OnSaleContext onSaleContext) {
            onSaleDataCheckPhase.check(onSaleContext);
        }
    
        private void process(OnSaleContext onSaleContext) {
            onSaleProcessPhase.process(onSaleContext);
        }
    }

    每个Phase又可以拆解成多个步骤(Step),以OnSaleProcessPhase为例,它是由一系列Step组成的:

    @Phase
    public class OnSaleProcessPhase {
    
        @Resource
        private PublishOfferStep publishOfferStep;
        @Resource
        private BackOfferBindStep backOfferBindStep;
        //省略其它step
    
        public void process(OnSaleContext onSaleContext){
            SupplierItem supplierItem = onSaleContext.getSupplierItem();
    
            // 生成OfferGroupNo
            generateOfferGroupNo(supplierItem);
           
           // 发布商品
            publishOffer(supplierItem);
    
            // 前后端库存绑定 backoffer域
            bindBackOfferStock(supplierItem);
    
            // 同步库存路由 backoffer域
            syncStockRoute(supplierItem);
    
            // 设置虚拟商品拓展字段
            setVirtualProductExtension(supplierItem);
    
            // 发货保障打标 offer域
            markSendProtection(supplierItem);
    
            // 记录变更内容ChangeDetail
            recordChangeDetail(supplierItem);
    
            // 同步供货价到BackOffer
            syncSupplyPriceToBackOffer(supplierItem);
    
            // 如果是组合商品打标,写扩展信息
            setCombineProductExtension(supplierItem);
    
            // 去售罄标
            removeSellOutTag(offerId);
    
            // 发送领域事件
            fireDomainEvent(supplierItem);
            
            // 关闭关联的待办事项
            closeIssues(supplierItem);
        }
    }

    看到了吗,这就是商品上架这个复杂业务的业务流程。需要流程引擎吗?不需要,需要设计模式支撑吗?也不需要。对于这种业务流程的表达,简单朴素的组合方法模式(Composed Method)是再合适不过的了。

    因此,在做过程分解的时候,我建议工程师不要把太多精力放在工具上,放在设计模式带来的灵活性上。而是应该多花时间在对问题分析,结构化分解,最后通过合理的抽象,形成合适的阶段(Phase)和步骤(Step)上。

    过程分解后的两个问题

    的确,使用过程分解之后的代码,已经比以前的代码更清晰、更容易维护了。不过,还有两个问题值得我们去关注一下:

    1、领域知识被割裂肢解

    什么叫被肢解?因为我们到目前为止做的都是过程化拆解,导致没有一个聚合领域知识的地方。每个Use Case的代码只关心自己的处理流程,知识没有沉淀。

    相同的业务逻辑会在多个Use Case中被重复实现,导致代码重复度高,即使有复用,最多也就是抽取一个util,代码对业务语义的表达能力很弱,从而影响代码的可读性和可理解性。

    2、代码的业务表达能力缺失

    试想下,在过程式的代码中,所做的事情无外乎就是取数据--做计算--存数据,在这种情况下,要如何通过代码显性化的表达我们的业务呢? 说实话,很难做到,因为我们缺失了模型,以及模型之间的关系。脱离模型的业务表达,是缺少韵律和灵魂的。

    举个例子,在上架过程中,有一个校验是检查库存的,其中对于组合品(CombineBackOffer)其库存的处理会和普通品不一样。原来的代码是这么写的:

    boolean isCombineProduct = supplierItem.getSign().isCombProductQuote();
    
    // supplier.usc warehouse needn't check
    if (WarehouseTypeEnum.isAliWarehouse(supplierItem.getWarehouseType())) {
    // quote warehosue check
    if (CollectionUtil.isEmpty(supplierItem.getWarehouseIdList()) && !isCombineProduct) {
        throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!");
    }
    // inventory amount check
    Long sellableAmount = 0L;
    if (!isCombineProduct) {
        sellableAmount = normalBiz.acquireSellableAmount(supplierItem.getBackOfferId(), supplierItem.getWarehouseIdList());
    } else {
        //组套商品
        OfferModel backOffer = backOfferQueryService.getBackOffer(supplierItem.getBackOfferId());
        if (backOffer != null) {
            sellableAmount = backOffer.getOffer().getTradeModel().getTradeCondition().getAmountOnSale();
        }
    }
    if (sellableAmount < 1) {
        throw ExceptionFactory.makeFault(ServiceExceptionCode.SYSTEM_ERROR, "亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + supplierItem.getId() + "]");
    }
    }

    然而,如果我们在系统中引入领域模型之后,其代码会简化为如下:

    if(backOffer.isCloudWarehouse()){
        return;
    }
    
    if (backOffer.isNonInWarehouse()){
        throw new BizException("亲,不能发布Offer,请联系仓配运营人员,建立品仓关系!");
    }
    
    if (backOffer.getStockAmount() < 1){
        throw new BizException("亲,实仓库存必须大于0才能发布,请确认已补货.\r[id:" + backOffer.getSupplierItem().getCspuCode() + "]");
    }  

    有没有发现,使用模型的表达要清晰易懂很多,而且也不需要做关于组合品的判断了,因为我们在系统中引入了更加贴近现实的对象模型(CombineBackOffer继承BackOffer),通过对象的多态可以消除我们代码中的大部分的if-else。

    过程分解+对象模型

    通过上面的案例,我们可以看到有过程分解要好于没有分解过程分解+对象模型要好于仅仅是过程分解。对于商品上架这个case,如果采用过程分解+对象模型的方式,最终我们会得到一个如下的系统结构:

    写复杂业务的方法论

    通过上面案例的讲解,我想说,我已经交代了复杂业务代码要怎么写:即自上而下的结构化分解+自下而上的面向对象分析

    接下来,让我们把上面的案例进行进一步的提炼,形成一个可落地的方法论,从而可以泛化到更多的复杂业务场景。

    上下结合

    所谓上下结合,是指我们要结合自上而下的过程分解和自下而上的对象建模,螺旋式的构建我们的应用系统。这是一个动态的过程,两个步骤可以交替进行、也可以同时进行。

    这两个步骤是相辅相成的,上面的分析可以帮助我们更好的理清模型之间的关系,而下面的模型表达可以提升我们代码的复用度和业务语义表达能力

    其过程如下图所示:

    使用这种上下结合的方式,我们就有可能在面对任何复杂的业务场景,都能写出干净整洁、易维护的代码。

    能力下沉

    一般来说实践DDD有两个过程:

    1. 套概念阶段

    了解了一些DDD的概念,然后在代码中“使用”Aggregation Root,Bonded Context,Repository等等这些概念。更进一步,也会使用一定的分层策略。然而这种做法一般对复杂度的治理并没有多大作用。

    2. 融会贯通阶段

    术语已经不再重要,理解DDD的本质是统一语言、边界划分和面向对象分析的方法。

    大体上而言,我大概是在1.7的阶段,因为有一个问题一直在困扰我,就是哪些能力应该放在Domain层,是不是按照传统的做法,将所有的业务都收拢到Domain上,这样做合理吗?说实话,这个问题我一直没有想清楚。

    因为在现实业务中,很多的功能都是用例特有的(Use case specific)的,如果“盲目”的使用Domain收拢业务并不见得能带来多大的益处。相反,这种收拢会导致Domain层的膨胀过厚,不够纯粹,反而会影响复用性和表达能力。

    鉴于此,我最近的思考是我们应该采用能力下沉的策略。

    所谓的能力下沉,是指我们不强求一次就能设计出Domain的能力,也不需要强制要求把所有的业务功能都放到Domain层,而是采用实用主义的态度,即只对那些需要在多个场景中需要被复用的能力进行抽象下沉,而不需要复用的,就暂时放在App层的Use Case里就好了。

    注:Use Case是《架构整洁之道》里面的术语,简单理解就是响应一个Request的处理过程

    通过实践,我发现这种循序渐进的能力下沉策略,应该是一种更符合实际、更敏捷的方法。因为我们承认模型不是一次性设计出来的,而是迭代演化出来的。

    下沉的过程如下图所示,假设两个use case中,我们发现uc1的step3和uc2的step1有类似的功能,我们就可以考虑让其下沉到Domain层,从而增加代码的复用性。

    指导下沉有两个关键指标:代码的复用性和内聚性

    复用性是告诉我们When(什么时候该下沉了),即有重复代码的时候。内聚性是告诉我们How(要下沉到哪里),功能有没有内聚到恰当的实体上,有没有放到合适的层次上(因为Domain层的能力也是有两个层次的,一个是Domain Service这是相对比较粗的粒度,另一个是Domain的Model这个是最细粒度的复用)。

    比如,在我们的商品域,经常需要判断一个商品是不是最小单位,是不是中包商品。像这种能力就非常有必要直接挂载在Model上。

    public class CSPU {
        private String code;
        private String baseCode;
        //省略其它属性
    
        /**
         * 单品是否为最小单位。
         *
         */
        public boolean isMinimumUnit(){
            return StringUtils.equals(code, baseCode);
        }
    
        /**
         * 针对中包的特殊处理
         *
         */
        public boolean isMidPackage(){
            return StringUtils.equals(code, midPackageCode);
        }
    }

    之前,因为老系统中没有领域模型,没有CSPU这个实体。你会发现像判断单品是否为最小单位的逻辑是以StringUtils.equals(code, baseCode)的形式散落在代码的各个角落。这种代码的可理解性是可想而知的,至少我在第一眼看到这个代码的时候,是完全不知道什么意思。

    业务技术要怎么做

    写到这里,我想顺便回答一下很多业务技术同学的困惑,也是我之前的困惑:即业务技术到底是在做业务,还是做技术?业务技术的技术性体现在哪里?

    通过上面的案例,我们可以看到业务所面临的复杂性并不亚于底层技术,要想写好业务代码也不是一件容易的事情。业务技术和底层技术人员唯一的区别是他们所面临的问题域不一样。

    业务技术面对的问题域变化更多、面对的人更加庞杂。而底层技术面对的问题域更加稳定、但对技术的要求更加深。比如,如果你需要去开发Pandora,你就要对Classloader有更加深入的了解才行。

    但是,不管是业务技术还是底层技术人员,有一些思维和能力都是共通的。比如,分解问题的能力,抽象思维,结构化思维等等。

    用我的话说就是:“做不好业务开发的,也做不好技术底层开发,反之亦然。业务开发一点都不简单,只是我们很多人把它做“简单”了

    因此,如果从变化的角度来看,业务技术的难度一点不逊色于底层技术,其面临的挑战甚至更大。因此,我想对广大的从事业务技术开发的同学说:沉下心来,夯实自己的基础技术能力、OO能力、建模能力... 不断提升抽象思维、结构化思维、思辨思维... 持续学习精进,写好代码。我们可以在业务技术岗做的很”技术“!

    后记

    这篇文章是我最近思考的一些总结,可能需要一些DDD和应用架构的知识做铺垫。否则的话,有些地方可能会显得有些唐突,或是没有那么有体感。


    原文链接
    本文为云栖社区原创内容,未经允许不得转载。

    展开全文
  • 在一个成熟的团队,CodeReview是整个研发流程不可或缺的一步,而那些即将走向成熟的团队可能对CodeReview有很多的误解和问题,也不清楚CodeReview该如何去做,本文笔者将结合自己的经验和知识,谈谈我对Code...
  • 什么是编程的脚手架

    千次阅读 2019-09-11 15:13:25
    在计算使用的脚手架的是两种技术之一: 第一种是与某些MVC 框架的数据库访问相关的代码生成技术; 第二种是由各种工具支持的项目生成技术。 由此,我们明确了脚手架的定义:脚手架作用是创建项目的初始文件,...
  • 什么是代码(Low-Code)?

    万次阅读 多人点赞 2020-11-17 15:28:22
    那么在后疫情时代,究竟需要什么样的新技术,才能真正解放IT生产力,加速社会数字化转型,Make The World Great Again?我认为是低代码(Low-Code)。
  • 什么是代码平台 low-code?

    千次阅读 2021-02-02 09:32:01
    简介:什么是代码?我们为什么需要低代码?低代码会让程序员失业吗?本文总结了低代码领域的基本概念、核心价值与行业现状,带你全面了解低代码。 一 前言 如果选择用一个关键词来代表即将过去的2020年,我相信...
  • 天天写业务代码的那些年,我们是如何成长过来的

    万次阅读 多人点赞 2017-04-12 21:02:37
    比起写业务代码更不幸的是,主要工作是修 Bug,bug,buG, bUg。 在一家大的公司里,不同的人总会有不同的运气: 运气好的人遇上一个好的项目,升职加薪,从此就走上了人生的巅峰。 运气差的人摊上一个差的项目,升不...
  • 什么是代码?白码详解

    千次阅读 2020-05-13 10:20:03
    现在很多的企业想要开发应用程序一般都会选择外部公司来处理,但是随着应用程序需求的不断增加,外包公司的开发速度已经跟不上企业的需求,这就导致大量的应用程序开发积压。...零代码围绕企业数据和业务管理需求,
  • 如今,低代码平台已经成为众多企业在数字化转型升级中的重要手段,也是中国企业数智化服务市场的一大热点。 2022年,低代码平台将会有哪些重要变化?请看中国软件行业协会、海比研究院联合国内低代码平台的领导...
  • 1小时学会不打代码制作一个网页精美简历(1)

    万次阅读 多人点赞 2021-05-13 22:39:48
    系列教程将会在流量降低时转为付费位置,流量多时将不会,各位抓紧时间学习哟~ 什么是代码什么是 IVX 小媛:bit 哥,我学了很多东西,例如 php、java、html之类,可是都做不了一个应用怎么办? 1_bit:你是...
  • 代码平台是一种能够帮助企业快速交付业务应用的平台。自2000年以来,低代码市场一直充斥着40+大大小小的各种玩家,比如国外的Appian、K2、Pega Systems、Salesforce和Ultimus,国内的H3 BPM和炎黄盈动。 2015年...
  • 什么是代码

    千次阅读 2018-03-29 00:00:00
    本文转载自公众号 码农翻身“什么狗屁代码,老子看了几个小时也没明白...什么是好的代码? 这个问题可能是仁者见仁,智者见智。 我先说说我的看法,欢迎大家留言讨论。 我个人觉得好代码分为两个层面, 一个是道,一
  • 什么是to B 业务

    万次阅读 2017-08-16 18:16:20
    引言 | To B or Not to B, there is not a question。对于企业而言,数据分析的作用主要体现在三大领域:(1)是对业务的改进优化;... B or Not to B, there is not a question——(一)什么是to B 业务
  • JavaBean实际上是一种特殊的Java类,它通常用来实现一些比较常用的简单功能,并可以很容易的被重用或者是插入其他应用程序去。所有遵循一定编程原则的Java类都可以被称作JavaBean。一. Java Bean技术概述Java ...
  • 复杂业务代码要怎么写

    万次阅读 多人点赞 2019-08-01 18:33:14
    面对零售通如此复杂的业务场景,如何在架构和代码层面进行应对,我有了一些新的思考,在此分享给大家。我相信,同样的方法论可以复制到大部分复杂业务场景。 一个复杂业务的处理过程 业务背景 简单的介绍下业务背景...
  • 代码Review那些事

    万次阅读 多人点赞 2016-04-27 20:18:19
    代码Review那些事
  • 1、解读台 -- 什么是中

    千次阅读 2019-10-06 18:57:15
    解读台,通过对业务、数据和技术的抽象,对服务能力进行复用,构建了企业级的服务能力,消除了企业内部各业务部门、各分子...什么是中台是一个新的概念,但却是一个旧有的名词,在新时期赋予其新的内涵; ...
  • 代码规范和架构设计是软件的灵魂所在,代码质量偏低,就像是人失去了三魂七魄的一魄,就会丧失活力,影响正常运行,增加软件交付后维护成本,出现推迟完成、超出预算、特性缺失等现象。 任何语言都需要强调编码...
  • 很多开发者为天天写业务代码无暇提升技术而焦虑、苦恼,比如: 又如: 又如: ...那么,作为开发者,到底该怎么面对“写...如何从写业务代码中跳出来,做你所谓的有技术含量的工作 我们先来看看,什么是业务
  • 无码系列5.1 代码重构 消除重复代码

    千次阅读 2019-08-22 15:11:55
    1 前言 本文可以视为对ThoughtWorks高级顾问yuanyingjie关于“正交四原则”策略“消除重复”的...“实战篇” 章节是近期笔者代码练习而写, 是一个真实的代码演进过程。 这份代码的复杂度刚好切合了“重构”思路的...
  • 先声明一下,本文不聊ISSUE的七七八八,也不聊代码是否写的好,更不聊是不是跟蔡徐坤有关之类的吃瓜内容。仅站在技术人的角度,从这次的代码泄露事件,聊聊在代码的安全管理上,通常都需要做哪些事来预防此类事件...
  • 经常听说祖传代码会被人称之为「屎山」,不同人可能有不同的体会,最近看到一个回答,简直是把这个阐述得“活灵活现”,大家来感受下吧。“ 阅读本文大概需要 3 分钟。 ”作者:Avalon原文...
  • 代码又火了。 近几年,腾讯、阿里、百度等互联网大厂纷纷入局,国内外低代码平台融资动辄数千万甚至数亿,以及伴随着热度而来的巨大争议……无不说明“低代码”的火爆。 事实上,低代码并非新概念,它可以追溯到上...
  • 10分钟认识低代码平台

    千次阅读 2022-01-18 20:22:45
    了解低代码的概念和分类,以及如何选择低代码平台,同时也将低代码的市场和局限性做说明
  • 代码有这16个好习惯,可以减少80%非业务的bug

    万次阅读 多人点赞 2020-11-26 00:10:50
    前言每一个好习惯都是一笔财富,本文整理了写代码的16个好习惯,每个都很经典,养成这些习惯,可以规避多数非业务的bug!希望对大家有帮助哈,谢谢阅读,加油哦~github地址,感谢每颗st...
  • 使用“不用写代码的IDE”是一种怎样的体验?

    千次阅读 多人点赞 2021-05-27 11:39:22
    可能有些人还不知道我的是啥,以一款今年比较流行的全自动软件开发平台为例,所谓「全自动」,就是你在开发一个项目时,不需要你写代码,只需要你画好对应的逻辑流程图,平台便可以自动帮你生成对应的代码。...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 342,602
精华内容 137,040
关键字:

代码中的业务是指什么