江苏龙网

  1. 首页 > 人文 > >

「InfoQ」怎样才能实现软件架构的“代代相传”？( 四 )


按照构件化设计理念 ， 构件可以独立部署 ， 但一个构件可能会用到其它构件或平台提供的服务 ， 或者说基于构件的软件系统通常是多个构件协作完成一定功能 ， 所以构件依赖于组装环境或称为语境（context） ， 而构件基础设施应是支持异构构件互操作的标准和通信平台 ， 构件框架则是构件实例“即插即用”的支撑结构 。
CBD 的实现方式之一就是大家耳熟能详的——SOA（Service Oriented Architecture， 面向服务的体系结构）或者 SCA（Service Component Architecture， 服务组件体系结构） 。 从发展脉络上讲 ， 1990 年左右就开始出现面向构件的技术思想 ， 也即 ， 编程方法在面向对象后是面向构件 ， 然后才是面向服务 。
关于构件化设计 ， 国家标准也早已有之 ， 比如 GB/T11457-2006 软件工程过程、GB/T36445-2018 软件构件模型 ， 都有相关技术标准约定 ， 但是这些标准都未包含构件的设计方法 ， 实践中大家更关心的是如何做出标准化构件的方法论 。
有人经常用“乐高积木”一词来形容构件化或服务化设计方式 ， 乐高积木之所以会吸引不同年龄段的人群 ， 并能让大家充分发挥创造力 ， 主要原因不外乎两点：一是接口的高度标准化 ， 可以简单搭接；二是使用者能很轻易地理解每个积木块 ， 自由运用它 。
构件模型设计的关键也在于这两点 。 设计行业级标准化构件模型 ， 首先是接口的高度标准化 ， 这一点有赖于前文中提到的数据标准化；二是构件功能的标准化和可理解性 ， 这就涉及到对业务行为的标准化 ， 或者说对各种同类型企业（也存在同类型企业中按照规模等级再细分的可能）的业务活动标准化 ， 这种标准形成需要以业务为核心的建模方法 ， 也需要通过作为参照系的标杆企业来提炼标准业务行为 。
在建模方法中 ， Alan W.Brown 在《Large-Scale, Component-Based Development》一书中给出的主要是基于 UML 的方法 ， 该方法虽然与现实结合紧密 ， 但对业务人员不够友好；DDD 也是可以应用于构件化设计的建模方法 ， 尤其是在以构建微服务为应用方向运用 DDD 方法时 ， 该方法也充分考虑了业务含义 。 笔者在《企业级业务架构设计：方法论与实践》一书中提到的构件模型也是一种可用的构建方式 ， 其优点是具有企业级视角 ， 与业务和技术两端结合紧密 ， 也适合于推导行业标准模型这种精炼性工作 。
综上 ， 数据标准化和行为标准化的探索一直有人在进行 ， 但需要更强有力的推动来真正形成行业级的标准 ， 否则 ， 软件的发展有可能在“凶猛”的创新下反倒出现“作茧自缚”的情况 。
3
行业级标准化的深远影响
行业级标准化的价值有很多 ， 比如有助于提升软件资产的可重用性、提升软件质量、减少不必要的改动、提升互联效率、提高需求质量、提升需求形成效率等 ， 这些价值很多文章都提出过 ， 笔者在本文中想阐述一个目前较少提及的远期价值：推动数字化思维转型 。
数字化时代是依靠大规模软件生产支持社会生产的时代 ， 如同今天工业的作用 。 而大规模软件生产能力的形成需要与之相匹配的思维方式 ， 人们的思维方式总是要与时代的主要生产方式相适应 ， 当软件成为主要的生产方式时 ， 结构化思维就成为这个时代最基础的思维方式 ， 提升所有参与者的结构化思维能力是面向数字化时代最重要的思维转型方向 ， 包括业务人员的思维转型和技术人员的思维转型 。
业务人员思维转型 ， 是指能结构化地看待业务、理解业务 ， 结构化的业务视角更有利于将业务映射到技术实现 ， 也更有利于业务人员较为直接地应用已有的软件资产 ， 如同业务人员看到“乐高积木” ， 具备结构化思维能力的业务人员 ， 更容易适应在数字化时代看到的“事物”和从事业务活动、开展业务创新的方式 。
技术人员思维转型 ， 则是要能结构化地看待业务构成与技术实现的关系 ， 从而更好地将业务分解成合适的“零件” ， 这是在技术人员原有结构化思维方式上的一种深化 。 对技术人员而言 ， 这还意味着要更主动地去接受标准化的“约束” ， 从个体化的改进软件向公用化的改进“标准”发展 ， 这是数字化时代进行大规模软件生产需要的技术思维方式 。


推荐阅读


上一篇：【栈外】第三方Cookie的消失对广告商来说意味着什么？

下一篇：「上观新闻」盒马首单运费终于归零，透露了哪些信息？